| |
| RFC 7600 | IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd) |
| |
| Authors: | R. Despres, S. Jiang, Ed., R. Penno, Y. Lee, G. Chen, M. Chen. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7600 |
|
This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offeringIPv4 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. |
|
| |
| RFC 7601 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
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. |
|
| |
| RFC 7602 | IS-IS Extended Sequence Number TLV |
| |
| Authors: | U. Chunduri, W. Lu, A. Tian, N. Shen. |
| Date: | July 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7602 |
|
This document defines the Extended Sequence Number TLV to protectIntermediate System to Intermediate System (IS-IS) PDUs from replay attacks. |
|
| |
| RFC 7603 | Energy Management (EMAN) Applicability Statement |
| |
| Authors: | B. Schoening, M. Chandramouli, B. Nordman. |
| Date: | August 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7603 |
|
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. |
|
| |
| RFC 7604 | Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) |
| |
| Authors: | M. Westerlund, T. Zeng. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7604 |
|
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. |
|
| |
| RFC 7605 | Recommendations on Using Assigned Transport Port Numbers |
| |
|
|
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.It provides guidelines for designers regarding how to interact with the IANA processes defined in RFC 6335, thus serving to complement(but not update) that document. |
|
| |
| RFC 7606 | Revised Error Handling for BGP UPDATE Messages |
| |
| Authors: | E. Chen, Ed., J. Scudder, Ed., P. Mohapatra, K. Patel. |
| Date: | August 2015 |
| Formats: | txt html json |
| Updates: | RFC 1997, RFC 4271, RFC 4360, RFC 4456, RFC 4760, RFC 5543, RFC 5701, RFC 6368 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7606 |
|
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. |
|
| |
| RFC 7607 | Codification of AS 0 Processing |
| |
| Authors: | W. Kumari, R. Bush, H. Schiller, K. Patel. |
| Date: | August 2015 |
| Formats: | txt html json |
| Updates: | RFC 4271 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7607 |
|
This document updates RFC 4271 and proscribes the use of AutonomousSystem (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH,AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message. |
|
| |
| RFC 7608 | IPv6 Prefix Length Recommendation for Forwarding |
| |
| Authors: | M. Boucadair, A. Petrescu, F. Baker. |
| Date: | July 2015 |
| Formats: | txt json html |
| Also: | BCP 0198 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7608 |
|
IPv6 prefix length, as in IPv4, is a parameter conveyed and used inIPv6 routing and forwarding processes in accordance with theClassless Inter-domain Routing (CIDR) architecture. The length of anIPv6 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. |
|
| |
| RFC 7609 | IBM's Shared Memory Communications over RDMA (SMC-R) Protocol |
| |
| Authors: | M. Fox, C. Kassimis, J. Stevens. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7609 |
|
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. |
|
| |
| RFC 7610 | DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers |
| |
| Authors: | F. Gont, W. Liu, G. Van de Velde. |
| Date: | August 2015 |
| Formats: | txt json html |
| Also: | BCP 0199 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 7610 |
|
This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based onDHCPv6 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. |
|
| |
| RFC 7611 | BGP ACCEPT_OWN Community Attribute |
| |
| Authors: | J. Uttaro, P. Mohapatra, D. Smith, R. Raszuk, J. Scudder. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7611 |
|
Under certain conditions, it is desirable for a Border GatewayProtocol (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 samePE. 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. |
|
| |
| RFC 7612 | Lightweight Directory Access Protocol (LDAP): Schema for Printer Services |
| |
|
|
This document defines a schema, object classes, and attributes, forPrinters 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 "InternetPrinting Protocol/1.1: Model and Semantics" (RFC 2911). AdditionalPrinter attributes are based on definitions in "Printer MIB v2" (RFC3805), "PWG Command Set Format for IEEE 1284 Device ID v1.0" (PWG5107.2), "IPP Job and Printer Extensions - Set 3 (JPS3)" (PWG5100.13), and "IPP Everywhere" (PWG 5100.14).
This memo is an Independent Submission to the RFC Editor by theInternet Printing Protocol (IPP) Working Group of the IEEE-ISTOPrinter Working Group (PWG), as part of their PWG "IPP Everywhere"(PWG 5100.14) project for secure mobile printing with vendor-neutralClient software.
This document obsoletes RFC 3712. |
|
| |
| RFC 7613 | Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords |
| |
|
|
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 RFC3454, and this document obsoletes RFC 4013. |
|
| |
| RFC 7614 | Explicit Subscriptions for the REFER Method |
| |
| Authors: | R. Sparks. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7614 |
|
The Session Initiation Protocol (SIP) REFER request, as defined byRFC 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. |
|
| |
| RFC 7615 | HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields |
| |
|
|
This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HypertextTransfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted. |
|
| |
| RFC 7616 | HTTP Digest Access Authentication |
| |
| Authors: | R. Shekh-Yusef, Ed., D. Ahrens, S. Bremer. |
| Date: | September 2015 |
| Formats: | txt html json |
| Obsoletes: | RFC 2617 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7616 |
|
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. |
|
| |
| RFC 7617 | The 'Basic' HTTP Authentication Scheme |
| |
|
|
This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. |
|
| |
| RFC 7618 | Dynamic Allocation of Shared IPv4 Addresses |
| |
| Authors: | Y. Cui, Q. Sun, I. Farrer, Y. Lee, Q. Sun, M. Boucadair. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7618 |
|
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. |
|
| |
| RFC 7619 | The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
This document specifies the NULL Authentication method and theID_NULL Identification Payload ID Type for Internet Key ExchangeProtocol 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 OpportunisticSecurity (also known as Opportunistic Encryption) to defend againstPervasive Monitoring attacks without the need to sacrifice anonymity. |
|
| |
| RFC 7620 | Scenarios with Host Identification Complications |
| |
| Authors: | M. Boucadair, Ed., B. Chatras, T. Reddy, B. Williams, B. Sarikaya. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7620 |
|
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. |
|
| |
| RFC 7621 | A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework |
| |
|
|
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. |
|
| |
| RFC 7622 | Extensible Messaging and Presence Protocol (XMPP): Address Format |
| |
|
|
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. |
|
| |
| RFC 7623 | Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN) |
| |
| Authors: | A. Sajassi, Ed., S. Salam, N. Bitar, A. Isaac, W. Henderickx. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7623 |
|
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/ClientMAC (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. |
|
| |
| RFC 7624 | Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement |
| |
| Authors: | R. Barnes, B. Schneier, C. Jennings, T. Hardie, B. Trammell, C. Huitema, D. Borkmann. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7624 |
|
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. |
|
| |
| RFC 7625 | Architecture of an IP/MPLS Network with Hardened Pipes |
| |
| Authors: | J. T. Hao, P. Maheshwari, R. Huang, L. Andersson, M. Chen. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7625 |
|
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 LabelSwitched 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 theLSPs 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. |
|
| |
| RFC 7626 | DNS Privacy Considerations |
| |
|
|
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. |
|
| |
| RFC 7627 | Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension |
| |
| Authors: | K. Bhargavan, Ed., A. Delignat-Lavaud, A. Pironti, A. Langley, M. Ray. |
| Date: | September 2015 |
| Formats: | txt html json |
| Updates: | RFC 5246 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7627 |
|
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. |
|
| |
| RFC 7628 | A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth |
| |
| Authors: | W. Mills, T. Showalter, H. Tschofenig. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7628 |
|
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. |
|
| |
| RFC 7629 | Flow-Binding Support for Mobile IP |
| |
| Authors: | S. Gundavelli, Ed., K. Leung, G. Tsirtsis, A. Petrescu. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7629 |
|
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. |
|
| |
| RFC 7630 | HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 |
| |
| Authors: | J. Merkle, Ed., M. Lochter. |
| Date: | October 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7860 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7630 |
|
This memo specifies new HMAC-SHA-2 authentication protocols for theUser-based Security Model (USM) for SNMPv3 defined in RFC 3414. |
|
| |
| RFC 7631 | TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format |
| |
|
|
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 toRFC 5444. |
|
| |
| RFC 7632 | Endpoint Security Posture Assessment: Enterprise Use Cases |
| |
| Authors: | D. Waltermire, D. Harrington. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7632 |
|
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. |
|
| |
| RFC 7633 | X.509v3 Transport Layer Security (TLS) Feature Extension |
| |
| Authors: | P. Hallam-Baker. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7633 |
|
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 OnlineCertificate 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. |
|
| |
| RFC 7634 | ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec |
| |
| Authors: | Y. Nir. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7634 |
|
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. |
|
| |
| RFC 7635 | Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization |
| |
| Authors: | T. Reddy, P. Patil, R. Ravindranath, J. Uberti. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7635 |
|
This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities forNAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. |
|
| |
| RFC 7636 | Proof Key for Code Exchange by OAuth Public Clients |
| |
| Authors: | N. Sakimura, Ed., J. Bradley, N. Agarwal. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7636 |
|
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"). |
|
| |
| RFC 7637 | NVGRE: Network Virtualization Using Generic Routing Encapsulation |
| |
| Authors: | P. Garg, Ed., Y. Wang, Ed.. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7637 |
|
This document describes the usage of the Generic RoutingEncapsulation (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. |
|
| |
| RFC 7638 | JSON Web Key (JWK) Thumbprint |
| |
| Authors: | M. Jones, N. Sakimura. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7638 |
|
This specification defines a method for computing a hash value over aJSON 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. |
|
| |
| RFC 7639 | The ALPN HTTP Header Field |
| |
| Authors: | A. Hutton, J. Uberti, M. Thomson. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7639 |
|
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. |
|
| |
| RFC 7640 | Traffic Management Benchmarking |
| |
| Authors: | B. Constantine, R. Krishnan. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7640 |
|
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. |
|
| |
| RFC 7641 | Observing Resources in the Constrained Application Protocol (CoAP) |
| |
|
|
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. |
|
| |
| RFC 7642 | System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements |
| |
| Authors: | K. LI, Ed., P. Hunt, B. Khasnabish, A. Nadalin, Z. Zeltsan. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7642 |
|
This document provides definitions and an overview of the System forCross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements. |
|
| |
| RFC 7643 | System for Cross-domain Identity Management: Core Schema |
| |
| Authors: | P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7643 |
|
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. |
|
| |
| RFC 7644 | System for Cross-domain Identity Management: Protocol |
| |
| Authors: | P. Hunt, Ed., K. Grizzle, M. Ansari, E. Wahlstroem, C. Mortimore. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7644 |
|
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. |
|
| |
| RFC 7645 | The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis |
| |
| Authors: | U. Chunduri, A. Tian, W. Lu. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7645 |
|
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. |
|
| |
| RFC 7646 | Definition and Use of DNSSEC Negative Trust Anchors |
| |
| Authors: | P. Ebersman, W. Kumari, C. Griffiths, J. Livingood, R. Weber. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7646 |
|
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 NegativeTrust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains. |
|
| |
| RFC 7647 | Clarifications for the Use of REFER with RFC 6665 |
| |
| Authors: | R. Sparks, A.B. Roach. |
| Date: | September 2015 |
| Formats: | txt json html |
| Updates: | RFC 3515 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7647 |
|
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. |
|
| |
| RFC 7648 | Port Control Protocol (PCP) Proxy Function |
| |
| Authors: | S. Perreault, M. Boucadair, R. Penno, D. Wing, S. Cheshire. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7648 |
|
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. |
|
| |
| RFC 7649 | The Jabber Scribe Role at IETF Meetings |
| |
| Authors: | P. Saint-Andre, D. York. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7649 |
|
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. |
|
| |
| RFC 7650 | A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | J. Jimenez, J. Lopez-Vega, J. Maenpaa, G. Camarillo. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7650 |
|
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 allowsCoAP 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 theRELOAD overlay itself, without the use of centralized servers. TheRELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged. |
|
| |
| RFC 7651 | 3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | A. Dodd-Noble, S. Gundavelli, J. Korhonen, F. Baboescu, B. Weis. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7651 |
|
This document defines two new configuration attributes for theInternet Key Exchange Protocol version 2 (IKEv2). These attributes can be used for carrying the IPv4 address and IPv6 address of theProxy-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. |
|
| |
| RFC 7652 | Port Control Protocol (PCP) Authentication Mechanism |
| |
| Authors: | M. Cullen, S. Hartman, D. Zhang, T. Reddy. |
| Date: | September 2015 |
| Formats: | txt json html |
| Updates: | RFC 6887 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7652 |
|
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. |
|
| |
| RFC 7653 | DHCPv6 Active Leasequery |
| |
| Authors: | D. Raghuvanshi, K. Kinnear, D. Kukrety. |
| Date: | October 2015 |
| Formats: | txt json html |
| Updates: | RFC 5460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7653 |
|
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 theDHCPv6 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 viaTCP. This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options. |
|
| |
| RFC 7654 | Benchmarking Methodology for In-Service Software Upgrade (ISSU) |
| |
| Authors: | S. Banks, F. Calabria, G. Czirjak, R. Machat. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7654 |
|
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 SoftwareUpgrade (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. |
|
| |
| RFC 7655 | RTP Payload Format for G.711.0 |
| |
| Authors: | M. Ramalho, Ed., P. Jones, N. Harada, M. Perumal, L. Miao. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7655 |
|
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 theG.711.0 RTP payload format. |
|
| |
| RFC 7656 | A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources |
| |
| Authors: | J. Lennox, K. Gross, S. Nandakumar, G. Salgueiro, B. Burman, Ed.. |
| Date: | November 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7656 |
|
The terminology about, and associations among, Real-time TransportProtocol (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. |
|
| |
| RFC 7657 | Differentiated Services (Diffserv) and Real-Time Communication |
| |
| Authors: | D. Black, Ed., P. Jones. |
| Date: | November 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7657 |
|
This memo describes the interaction between Differentiated Services(Diffserv) network quality-of-service (QoS) functionality and real- time network communication, including communication based on theReal-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 theseDiffserv aspects for real-time network communication, includingWebRTC. |
|
| |
| RFC 7658 | Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs) |
| |
| Authors: | S. Perreault, T. Tsou, S. Sivakumar, T. Taylor. |
| Date: | October 2015 |
| Formats: | txt html json |
| Obsoletes: | RFC 4008 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7658 |
|
This memo deprecates MIB module NAT-MIB, a portion of the ManagementInformation 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 RFC4008 are included in this version unchanged with only the STATUS changed to deprecated. |
|
| |
| RFC 7659 | Definitions of Managed Objects for Network Address Translators (NATs) |
| |
| Authors: | S. Perreault, T. Tsou, S. Sivakumar, T. Taylor. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7659 |
|
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). |
|
| |
| RFC 7660 | Diameter Congestion and Filter Attributes |
| |
| Authors: | L. Bertz, S. Manning, B. Hirschman. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7660 |
|
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 minimalDiameter 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 theFilter-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. |
|
| |
| RFC 7661 | Updating TCP to Support Rate-Limited Traffic |
| |
| Authors: | G. Fairhurst, A. Sathiaseelan, R. Secchi. |
| Date: | October 2015 |
| Formats: | txt html json |
| Obsoletes: | RFC 2861 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7661 |
|
This document provides a mechanism to address issues that arise whenTCP 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 usingTCP while also providing an appropriate response if congestion is experienced.
This document also evaluates the Experimental specification of TCPCongestion 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. |
|
| |
| RFC 7662 | OAuth 2.0 Token Introspection |
| |
| Authors: | J. Richer, Ed.. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7662 |
|
This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of anOAuth 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. |
|
| |
| RFC 7663 | Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) |
| |
| Authors: | B. Trammell, Ed., M. Kuehlewind, Ed.. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7663 |
|
The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute ofTechnology (ETH) Zurich hosted the Stack Evolution in a MiddleboxInternet (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. |
|
| |
| RFC 7664 | Dragonfly Key Exchange |
| |
| Authors: | D. Harkins, Ed.. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7664 |
|
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 ForumResearch Group (CFRG). |
|
| |
| RFC 7665 | Service Function Chaining (SFC) Architecture |
| |
| Authors: | J. Halpern, Ed., C. Pignataro, Ed.. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7665 |
|
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 theIETF. This document does not propose solutions, protocols, or extensions to existing protocols. |
|
| |
| RFC 7666 | Management Information Base for Virtual Machines Controlled by a Hypervisor |
| |
| Authors: | H. Asai, M. MacFaden, J. Schoenwaelder, K. Shima, T. Tsou. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7666 |
|
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). |
|
| |
| RFC 7667 | RTP Topologies |
| |
| Authors: | M. Westerlund, S. Wenger. |
| Date: | November 2015 |
| Formats: | txt json html |
| Obsoletes: | RFC 5117 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7667 |
|
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.
This document is updated with additional topologies and replaces RFC5117. |
|
| |
| RFC 7668 | IPv6 over BLUETOOTH(R) Low Energy |
| |
| Authors: | J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. Shelby, C. Gomez. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7668 |
|
Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the BluetoothSpecial 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 PersonalArea Network (6LoWPAN) techniques. |
|
| |
| RFC 7669 | Assigning Digital Object Identifiers to RFCs |
| |
| Authors: | J. Levine. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7669 |
|
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. |
|
| |
| RFC 7670 | Generic Raw Public-Key Support for IKEv2 |
| |
| Authors: | T. Kivinen, P. Wouters, H. Tschofenig. |
| Date: | January 2016 |
| Formats: | txt html json |
| Updates: | RFC 7296 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7670 |
|
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. |
|
| |
| RFC 7671 | The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance |
| |
| Authors: | V. Dukhovni, W. Hardaker. |
| Date: | October 2015 |
| Formats: | txt html json |
| Updates: | RFC 6698 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7671 |
|
This document clarifies and updates the DNS-Based Authentication ofNamed 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. |
|
| |
| RFC 7672 | SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) |
| |
| Authors: | V. Dukhovni, W. Hardaker. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7672 |
|
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 theInternet email backbone to one using encrypted and authenticatedTransport Layer Security (TLS). |
|
| |
| RFC 7673 | Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records |
| |
| Authors: | T. Finch, M. Miller, P. Saint-Andre. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7673 |
|
The DNS-Based Authentication of Named Entities (DANE) specification(RFC 6698) describes how to use TLSA resource records secured byDNSSEC (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 RFC6698. Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records. |
|
| |
| RFC 7674 | Clarification of the Flowspec Redirect Extended Community |
| |
|
|
This document updates RFC 5575 ("Dissemination of Flow SpecificationRules") to clarify the formatting of the BGP Flowspec RedirectExtended Community. |
|
| |
| RFC 7675 | Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness |
| |
| Authors: | M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7675 |
|
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 SessionTraversal Utilities for NAT (STUN) usage. |
|
| |
| RFC 7676 | IPv6 Support for Generic Routing Encapsulation (GRE) |
| |
| Authors: | C. Pignataro, R. Bonica, S. Krishnan. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7676 |
|
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. |
|
| |
| RFC 7677 | SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms |
| |
|
|
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. |
|
| |
| RFC 7678 | Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions |
| |
| Authors: | C. Zhou, T. Taylor, Q. Sun, M. Boucadair. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7678 |
|
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 specifiesDiameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose. |
|
| |
| RFC 7679 | A One-Way Delay Metric for IP Performance Metrics (IPPM) |
| |
| Authors: | G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed.. |
| Date: | January 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 2679 |
| Also: | STD 0081 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 7679 |
|
This memo defines a metric for one-way delay of packets acrossInternet paths. It builds on notions introduced and discussed in theIP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makesRFC 2679 obsolete. |
|
| |
| RFC 7680 | A One-Way Loss Metric for IP Performance Metrics (IPPM) |
| |
| Authors: | G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, Ed.. |
| Date: | January 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 2680 |
| Also: | STD 0082 |
| Status: | INTERNET STANDARD |
| DOI: | 10.17487/RFC 7680 |
|
This memo defines a metric for one-way loss of packets acrossInternet paths. It builds on notions introduced and discussed in theIP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makesRFC 2680 obsolete. |
|
| |
| RFC 7681 | Email Exchange of Secondary School Transcripts |
| |
| Authors: | J. Davin. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7681 |
|
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. |
|
| |
| RFC 7682 | Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration |
| |
| Authors: | D. McPherson, S. Amante, E. Osterweil, L. Blunk, D. Mitchell. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7682 |
|
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. |
|
| |
| RFC 7683 | Diameter Overload Indication Conveyance |
| |
| Authors: | J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand. |
| Date: | October 2015 |
| Formats: | txt json html |
| Updated by: | RFC 8581 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7683 |
|
This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance(DOIC). |
|
| |
| RFC 7684 | OSPFv2 Prefix/Link Attribute Advertisement |
| |
| Authors: | P. Psenak, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura, A. Lindem. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7684 |
|
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. |
|
| |
| RFC 7685 | A Transport Layer Security (TLS) ClientHello Padding Extension |
| |
|
|
This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size. |
|
| |
| RFC 7686 | The ".onion" Special-Use Domain Name |
| |
| Authors: | J. Appelbaum, A. Muffett. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7686 |
|
This document registers the ".onion" Special-Use Domain Name. |
|
| |
| RFC 7687 | Report from the Strengthening the Internet (STRINT) Workshop |
| |
| Authors: | S. Farrell, R. Wenning, B. Bos, M. Blanchet, H. Tschofenig. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7687 |
|
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. |
|
| |
| RFC 7688 | GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks |
| |
| Authors: | Y. Lee, Ed., G. Bernstein, Ed.. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7688 |
|
This document provides Generalized Multiprotocol Label Switching(GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with WavelengthSwitched 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. |
|
| |
| RFC 7689 | Signaling Extensions for Wavelength Switched Optical Networks |
| |
| Authors: | G. Bernstein, Ed., S. Xu, Y. Lee, Ed., G. Martinelli, H. Harai. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7689 |
|
This document provides extensions to Generalized Multiprotocol LabelSwitching (GMPLS) signaling for control of Wavelength SwitchedOptical 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. |
|
| |
| RFC 7690 | Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) |
| |
| Authors: | M. Byerly, M. Hite, J. Jaeggli. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7690 |
|
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. |
|
| |
| RFC 7691 | Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members |
| |
|
|
BCP 101 defines the start and end dates for the terms of IETFAdministrative Oversight Committee (IAOC) members; these terms have proven to be impractical. This memo updates BCP 101 to direct theIAOC to establish more practical start and end dates for terms ofIAOC members. |
|
| |
| RFC 7692 | Compression Extensions for WebSocket |
| |
| Authors: | T. Yoshino. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7692 |
|
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 theDEFLATE algorithm. |
|
| |
| RFC 7693 | The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) |
| |
| Authors: | M-J. Saarinen, Ed., J-P. Aumasson. |
| Date: | November 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7693 |
|
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). |
|
| |
| RFC 7694 | Hypertext Transfer Protocol (HTTP) Client-Initiated 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. |
|
| |
| RFC 7695 | Distributed Prefix Assignment Algorithm |
| |
| Authors: | P. Pfister, B. Paterson, J. Arkko. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7695 |
|
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. |
|
| |
| RFC 7696 | Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms |
| |
|
|
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. |
|
| |
| RFC 7697 | MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) |
| |
| Authors: | P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7697 |
|
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 theOperations, Administration, and Maintenance (OAM) identifiers forMultiprotocol Label Switching (MPLS) and the MPLS-based TransportProfile (TP). |
|
| |
| RFC 7698 | Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks |
| |
| Authors: | O. Gonzalez de Dios, Ed., R. Casellas, Ed., F. Zhang, X. Fu, D. Ceccarelli, I. Hussain. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7698 |
|
To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International TelecommunicationUnion Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new DenseWavelength 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 theGMPLS protocols will be defined in companion documents. |
|
| |
| RFC 7699 | Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers |
| |
|
|
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 StudyGroup 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. |
|
