| |
| RFC 7500 | Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries |
| |
| Authors: | R. Housley, Ed., O. Kolkman, Ed.. |
| Date: | April 2015 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8720 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7500 |
|
This document provides principles for the operation of InternetAssigned Numbers Authority (IANA) registries. |
|
| |
| RFC 7501 | Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration |
| |
| Authors: | C. Davids, V. Gurbani, S. Poretsky. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7501 |
|
This document provides a terminology for benchmarking the SessionInitiation 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 BorderControllers. 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. |
|
| |
| RFC 7502 | Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration |
| |
| Authors: | C. Davids, V. Gurbani, S. Poretsky. |
| Date: | April 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7502 |
|
This document provides a methodology for benchmarking the SessionInitiation 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 BorderControllers. 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. |
|
| |
| RFC 7503 | OSPFv3 Autoconfiguration |
| |
|
|
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 StateAdvertisements (LSAs). |
|
| |
| RFC 7504 | SMTP 521 and 556 Reply Codes |
| |
|
|
This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in anExperimental 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. |
|
| |
| RFC 7505 | A "Null MX" No Service Resource Record for Domains That Accept No Mail |
| |
| Authors: | J. Levine, M. Delany. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7505 |
|
Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for anA/AAAA record as a fallback. Unfortunately, this means that theA/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. |
|
| |
| RFC 7506 | IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | K. Raza, N. Akiya, C. Pignataro. |
| Date: | April 2015 |
| Formats: | txt json html |
| Updates: | RFC 4379 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7506 |
|
RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute mechanism in which the Router Alert Option (RAO) MUST be set in theIP header of the MPLS Echo Request messages and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on theReply 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 EchoRequest 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. |
|
| |
| RFC 7507 | TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks |
| |
|
|
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. |
|
| |
| RFC 7508 | Securing Header Fields with S/MIME |
| |
| Authors: | L. Cailleux, C. Bonatti. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7508 |
|
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'. |
|
| |
| RFC 7509 | RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics |
| |
| Authors: | R. Huang, V. Singh. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7509 |
|
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. |
|
| |
| RFC 7510 | Encapsulating MPLS in UDP |
| |
| Authors: | X. Xu, N. Sheth, L. Yong, R. Callon, D. Black. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7510 |
|
This document specifies an IP-based encapsulation for MPLS, calledMPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enableUDP-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. |
|
| |
| RFC 7511 | Scenic Routing for IPv6 |
| |
| Authors: | M. Wilhelm. |
| Date: | 1 April 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7511 |
|
This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "GreenIT", whereby packets will be routed to get as much fresh-air time as possible. |
|
| |
| RFC 7512 | The PKCS #11 URI Scheme |
| |
| Authors: | J. Pechanec, D. Moffat. |
| Date: | April 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7512 |
|
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 InterfaceStandard". |
|
| |
| RFC 7513 | Source Address Validation Improvement (SAVI) Solution for DHCP |
| |
| Authors: | J. Bi, J. Wu, G. Yao, F. Baker. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7513 |
|
This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a SourceAddress 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. |
|
| |
| RFC 7514 | Really Explicit Congestion Notification (RECN) |
| |
| Authors: | M. Luckie. |
| Date: | 1 April 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7514 |
|
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 andExplicit Congestion Notification (ECN). |
|
| |
| RFC 7515 | JSON Web Signature (JWS) |
| |
| Authors: | M. Jones, J. Bradley, N. Sakimura. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7515 |
|
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 WebAlgorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. |
|
| |
| RFC 7516 | JSON Web Encryption (JWE) |
| |
| Authors: | M. Jones, J. Hildebrand. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7516 |
|
JSON Web Encryption (JWE) represents encrypted content usingJSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSONWeb Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and MessageAuthentication Code (MAC) capabilities are described in the separateJSON Web Signature (JWS) specification. |
|
| |
| RFC 7517 | JSON Web Key (JWK) |
| |
| Authors: | M. Jones. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7517 |
|
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 ofJWKs. 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. |
|
| |
| RFC 7518 | JSON Web Algorithms (JWA) |
| |
| Authors: | M. Jones. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7518 |
|
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 severalIANA registries for these identifiers. |
|
| |
| RFC 7519 | JSON Web Token (JWT) |
| |
|
|
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 JSONWeb Signature (JWS) structure or as the plaintext of a JSON WebEncryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code(MAC) and/or encrypted. |
|
| |
| RFC 7520 | Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) |
| |
| Authors: | M. Miller. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7520 |
|
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. |
|
| |
| RFC 7521 | Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants |
| |
| Authors: | B. Campbell, C. Mortimore, M. Jones, Y. Goland. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7521 |
|
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 forOAuth 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. |
|
| |
| RFC 7522 | Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants |
| |
| Authors: | B. Campbell, C. Mortimore, M. Jones. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7522 |
|
This specification defines the use of a Security Assertion MarkupLanguage (SAML) 2.0 Bearer Assertion as a means for requesting anOAuth 2.0 access token as well as for client authentication. |
|
| |
| RFC 7523 | JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants |
| |
| Authors: | M. Jones, B. Campbell, C. Mortimore. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7523 |
|
This specification defines the use of a JSON Web Token (JWT) BearerToken as a means for requesting an OAuth 2.0 access token as well as for client authentication. |
|
| |
| RFC 7524 | Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) |
| |
| Authors: | Y. Rekhter, E. Rosen, R. Aggarwal, T. Morin, I. Grosclaude, N. Leymann, S. Saad. |
| Date: | May 2015 |
| Formats: | txt html json |
| Updated by: | RFC 8534 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7524 |
|
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 usingP2MP 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 beBGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS. |
|
| |
| RFC 7525 | Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
|
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. |
|
| |
| RFC 7526 | Deprecating the Anycast Prefix for 6to4 Relay Routers |
| |
|
|
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 theInternet 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. |
|
| |
| RFC 7527 | Enhanced Duplicate Address 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 NeighborDiscovery (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. |
|
| |
| RFC 7528 | A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association |
| |
| Authors: | P. Higgs, J. Piesing. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7528 |
|
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, ExtensibleMarkup Language (XML) Schemas, classification schemes, XML DocumentType Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by HbbTV. |
|
| |
| RFC 7529 | Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) |
| |
|
|
This document defines extensions to the Internet Calendaring andScheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines howCalendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules. |
|
| |
| RFC 7530 | Network File System (NFS) Version 4 Protocol |
| |
|
|
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 DataRepresentation (XDR) description document, RFC 7531, obsoletes RFC3530 as the definition of the NFS version 4 protocol. |
|
| |
| RFC 7531 | Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description |
| |
| Authors: | T. Haynes, Ed., D. Noveck, Ed.. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7531 |
|
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, theNFS 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 withRFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol. |
|
| |
| RFC 7532 | Namespace Database (NSDB) Protocol for Federated File Systems |
| |
| Authors: | J. Lentini, R. Tewari, C. Lever, Ed.. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7532 |
|
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. |
|
| |
| RFC 7533 | Administration Protocol for Federated File Systems |
| |
| Authors: | J. Lentini, R. Tewari, C. Lever, Ed.. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7533 |
|
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. |
|
| |
| RFC 7534 | AS112 Nameserver Operations |
| |
|
|
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated inRFC 1918 for private use within individual sites.
Devices in such environments may occasionally originate Domain NameSystem (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. |
|
| |
| RFC 7535 | AS112 Redirection Using DNAME |
| |
| Authors: | J. Abley, B. Dickson, W. Kumari, G. Michaelson. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7535 |
|
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. |
|
| |
| RFC 7536 | Large-Scale Broadband Measurement Use Cases |
| |
| Authors: | M. Linsner, P. Eardley, T. Burbridge, F. Sorensen. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7536 |
|
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-scaleMeasurement 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. |
|
| |
| RFC 7537 | IANA Registries for LSP Ping Code Points |
| |
|
|
RFCs 4379 and 6424 created name spaces for Multi-Protocol LabelSwitching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for DownstreamMapping object Flags (DS Flags), Multipath Types, Pad TLVs, andInterface 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. |
|
| |
| RFC 7538 | The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) |
| |
|
|
This document specifies the additional Hypertext Transfer Protocol(HTTP) status code 308 (Permanent Redirect). |
|
| |
| RFC 7539 | ChaCha20 and Poly1305 for IETF Protocols |
| |
|
|
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). |
|
| |
| RFC 7540 | Hypertext Transfer Protocol Version 2 (HTTP/2) |
| |
|
|
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, theHTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. |
|
| |
| RFC 7541 | HPACK: Header Compression for HTTP/2 |
| |
| Authors: | R. Peon, H. Ruellan. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7541 |
|
This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2. |
|
| |
| RFC 7542 | The Network Access Identifier |
| |
|
|
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. |
|
| |
| RFC 7543 | Covering Prefixes Outbound Route Filter for BGP-4 |
| |
| Authors: | H. Jeng, L. Jalil, R. Bonica, K. Patel, L. Yong. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7543 |
|
This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in VirtualHub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN(EVPN) networks. |
|
| |
| RFC 7544 | Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP) |
| |
|
|
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. |
|
| |
| RFC 7545 | Protocol to Access White-Space (PAWS) Databases |
| |
| Authors: | V. Chen, Ed., S. Das, L. Zhu, J. Malyar, P. McCann. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7545 |
|
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". |
|
| |
| RFC 7546 | Structure of the Generic Security Service (GSS) Negotiation Loop |
| |
| Authors: | B. Kaduk. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7546 |
|
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. |
|
| |
| RFC 7547 | Management of Networks with Constrained Devices: Problem Statement and Requirements |
| |
| Authors: | M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, U. Herberg. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7547 |
|
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. |
|
| |
| RFC 7548 | Management of Networks with Constrained Devices: Use Cases |
| |
| Authors: | M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, A. Sehgal. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7548 |
|
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). |
|
| |
| RFC 7549 | 3GPP SIP URI Inter-Operator Traffic Leg Parameter |
| |
| Authors: | C. Holmberg, J. Holm, R. Jesske, M. Dolly. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7549 |
|
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-BackUser 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).
The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible. |
|
| |
| RFC 7550 | Issues and Recommendations with Multiple Stateful DHCPv6 Options |
| |
|
|
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. |
|
| |
| RFC 7551 | RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) |
| |
| Authors: | F. Zhang, Ed., R. Jing, R. Gandhi, Ed.. |
| Date: | May 2015 |
| Formats: | txt json html |
| Updated by: | RFC 8537 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7551 |
|
This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label SwitchedPaths (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. TheREVERSE_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. |
|
| |
| RFC 7552 | Updates to LDP for IPv6 |
| |
|
|
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. |
|
| |
| RFC 7553 | The Uniform Resource Identifier (URI) DNS Resource Record |
| |
| Authors: | P. Faltstrom, O. Kolkman. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7553 |
|
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. |
|
| |
| RFC 7554 | Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement |
| |
| Authors: | T. Watteyne, Ed., M. Palattella, L. Grieco. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7554 |
|
This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium AccessControl (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. |
|
| |
| RFC 7555 | Proxy MPLS Echo Request |
| |
| Authors: | G. Swallow, V. Lim, S. Aldrin. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7555 |
|
This document defines a means of remotely initiating MultiprotocolLabel Switched Protocol (MPLS) Pings on Label Switched Paths. AnMPLS Proxy Ping Request is sent to any Label Switching Router along aLabel 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). |
|
| |
| RFC 7556 | Multiple Provisioning Domain Architecture |
| |
| Authors: | D. Anipko, Ed.. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7556 |
|
This document is a product of the work of the Multiple InterfacesArchitecture 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 aProvisioning 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. |
|
| |
| RFC 7557 | Extension Mechanism for the Babel Routing Protocol |
| |
|
|
This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126. |
|
| |
| RFC 7558 | Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions |
| |
| Authors: | K. Lynn, S. Cheshire, M. Blanchet, D. Migault. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7558 |
|
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 scalableDNS-SD. |
|
| |
| RFC 7559 | Packet-Loss Resiliency for Router Solicitations |
| |
| Authors: | S. Krishnan, D. Anipko, D. Thaler. |
| Date: | May 2015 |
| Formats: | txt json html |
| Updates: | RFC 4861 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7559 |
|
When an interface on a host is initialized, the host transmits RouterSolicitations 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 RouterSolicitations. |
|
| |
| RFC 7560 | Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback |
| |
| Authors: | M. Kuehlewind, Ed., R. Scheffenegger, B. Briscoe. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7560 |
|
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-TripTime (RTT). In contrast, ECN for other transport protocols, such asRTP/UDP and SCTP, is specified with more accurate ECN feedback.Recent new TCP mechanisms (like Congestion Exposure (ConEx) or DataCenter 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. |
|
| |
| RFC 7561 | Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN |
| |
| Authors: | J. Kaippallimalil, R. Pazhyannur, P. Yegani. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7561 |
|
This document provides guidelines for achieving end-to-end Quality ofService (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 andWi-Fi Multimedia - Admission Control (WMM-AC) describe methods forQoS 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 RFC7222 to enable implementation of end-to-end QoS. |
|
| |
| RFC 7562 | Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates |
| |
|
|
This document specifies the use of Digital Transmission ContentProtection (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 containingDTCP certificates issued by the Digital Transmission LicensingAdministrator (DTLA). |
|
| |
| RFC 7563 | Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option |
| |
| Authors: | R. Pazhyannur, S. Speicher, S. Gundavelli, J. Korhonen, J. Kaippallimalil. |
| Date: | June 2015 |
| Formats: | txt html json |
| Updates: | RFC 6757 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7563 |
|
The Access Network Identifier (ANI) mobility option was introduced inRFC 6757, "Access Network Identifier (ANI) Option for Proxy MobileIPv6". 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 theMAG group identifier. This specification also defines an ANI Update-Timer sub-option that determines when and how often the ANI option will be updated. |
|
| |
| RFC 7564 | PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols |
| |
|
|
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 asStringprep (RFC 3454). This document obsoletes RFC 3454. |
|
| |
| RFC 7565 | The 'acct' URI Scheme |
| |
| Authors: | P. Saint-Andre. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7565 |
|
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. |
|
| |
| RFC 7566 | Enumservice Registration for 'acct' URI |
| |
| Authors: | L. Goix, K. Li. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7566 |
|
This document registers an E.164 Number Mapping (ENUM) service for'acct' URIs (Uniform Resource Identifiers). |
|
| |
| RFC 7567 | IETF Recommendations Regarding Active Queue Management |
| |
|
|
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. |
|
| |
| RFC 7568 | Deprecating Secure Sockets Layer Version 3.0 |
| |
| Authors: | R. Barnes, M. Thomson, A. Pironti, A. Langley. |
| Date: | June 2015 |
| Formats: | txt json html |
| Updates: | RFC 5246 |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7568 |
|
The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, TransportLayer 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. |
|
| |
| RFC 7569 | Registry Specification for Mandatory Access Control (MAC) Security Label Formats |
| |
| Authors: | D. Quigley, J. Lu, T. Haynes. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7569 |
|
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. |
|
| |
| RFC 7570 | Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) |
| |
| Authors: | C. Margaria, Ed., G. Martinelli, S. Balls, B. Wright. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7570 |
|
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. |
|
| |
| RFC 7571 | GMPLS RSVP-TE Extensions for Lock Instruct and Loopback |
| |
| Authors: | J. Dong, M. Chen, Z. Li, D. Ceccarelli. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7571 |
|
This document specifies extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) andLoopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS(GMPLS) for the control plane. |
|
| |
| RFC 7572 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging |
| |
| Authors: | P. Saint-Andre, A. Houri, J. Hildebrand. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7572 |
|
This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session InitiationProtocol (SIP) and the Extensible Messaging and Presence Protocol(XMPP). |
|
| |
| RFC 7573 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions |
| |
| Authors: | P. Saint-Andre, S. Loreto. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7573 |
|
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). |
|
| |
| RFC 7574 | Peer-to-Peer Streaming Peer Protocol (PPSPP) |
| |
| Authors: | A. Bakker, R. Petrocco, V. Grishchenko. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7574 |
|
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 usingLow Extra Delay Background Transport (LEDBAT) for congestion control. |
|
| |
| RFC 7575 | Autonomic Networking: Definitions and Design Goals |
| |
| Authors: | M. Behringer, M. Pritikin, S. Bjarnason, A. Clemm, B. Carpenter, S. Jiang, L. Ciavaglia. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7575 |
|
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 AutonomicNetwork interact. This document is a product of the IRTF's NetworkManagement Research Group. |
|
| |
| RFC 7576 | General Gap Analysis for Autonomic Networking |
| |
| Authors: | S. Jiang, B. Carpenter, M. Behringer. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7576 |
|
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 ResearchGroup. |
|
| |
| RFC 7577 | Definition of Managed Objects for Battery Monitoring |
| |
| Authors: | J. Quittek, R. Winter, T. Dietz. |
| Date: | July 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7577 |
|
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. |
|
| |
| RFC 7578 | Returning Values from Forms: multipart/form-data |
| |
|
|
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 obsoletesRFC 2388. |
|
| |
| RFC 7579 | General Network Element Constraint Encoding for GMPLS-Controlled Networks |
| |
| Authors: | G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7579 |
|
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. |
|
| |
| RFC 7580 | OSPF-TE Extensions for General Network Element Constraints |
| |
| Authors: | F. Zhang, Y. Lee, J. Han, G. Bernstein, Y. Xu. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7580 |
|
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 TransportNetwork (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 ofGMPLS. |
|
| |
| RFC 7581 | Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks |
| |
| Authors: | G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7581 |
|
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 AssignmentInformation Model for Wavelength Switched Optical Networks" (RFC7446) shows what information is required at specific points in theWSON. 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 theWSON-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). |
|
| |
| RFC 7582 | Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels |
| |
|
|
A set of prior RFCs specify procedures for supporting multicast inBGP/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, and6625 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. |
|
| |
| RFC 7583 | DNSSEC Key Rollover Timing Considerations |
| |
| Authors: | S. Morris, J. Ihren, J. Dickinson, W. Mekking. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7583 |
|
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. |
|
| |
| RFC 7584 | Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs) |
| |
| Authors: | R. Ravindranath, T. Reddy, G. Salgueiro. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7584 |
|
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 handleSIP messages that carry ICE semantics in Session Description Protocol(SDP) and STUN messages received as part of the ICE procedures forNAT and Firewall traversal of multimedia sessions. |
|
| |
| RFC 7585 | Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) |
| |
| Authors: | S. Winter, M. McCauley. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7585 |
|
This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS overTransport Layer Security (RADIUS/TLS) or RADIUS over DatagramTransport Layer Security (RADIUS/DTLS). |
|
| |
| RFC 7586 | The Scalable Address Resolution Protocol (SARP) for Large Data Centers |
| |
| Authors: | Y. Nachum, L. Dunbar, I. Yerushalmi, T. Mizrahi. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7586 |
|
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. |
|
| |
| RFC 7587 | RTP Payload Format for the Opus Speech and Audio Codec |
| |
| Authors: | J. Spittka, K. Vos, JM. Valin. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7587 |
|
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. |
|
| |
| RFC 7588 | A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem |
| |
| Authors: | R. Bonica, C. Pignataro, J. Touch. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7588 |
|
This memo describes how many vendors have solved the Generic RoutingEncapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration. |
|
| |
| RFC 7589 | Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication |
| |
| Authors: | M. Badra, A. Luchuk, J. Schoenwaelder. |
| Date: | June 2015 |
| Formats: | txt json html |
| Obsoletes: | RFC 5539 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7589 |
|
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 ofNETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539. |
|
| |
| RFC 7590 | Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | P. Saint-Andre, T. Alkemade. |
| Date: | June 2015 |
| Formats: | txt json html |
| Updates: | RFC 6120 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7590 |
|
This document provides recommendations for the use of Transport LayerSecurity (TLS) in the Extensible Messaging and Presence Protocol(XMPP). This document updates RFC 6120. |
|
| |
| RFC 7591 | OAuth 2.0 Dynamic Client Registration Protocol |
| |
| Authors: | J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7591 |
|
This specification defines mechanisms for dynamically registeringOAuth 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. |
|
| |
| RFC 7592 | OAuth 2.0 Dynamic Client Registration Management Protocol |
| |
| Authors: | J. Richer, Ed., M. Jones, J. Bradley, M. Machulak. |
| Date: | July 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7592 |
|
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. |
|
| |
| RFC 7593 | The eduroam Architecture for Network Roaming |
| |
| Authors: | K. Wierenga, S. Winter, T. Wolniewicz. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7593 |
|
This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination ofIEEE 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. |
|
| |
| RFC 7594 | A Framework for Large-Scale Measurement of Broadband Performance (LMAP) |
| |
| Authors: | P. Eardley, A. Morton, M. Bagnulo, T. Burbridge, P. Aitken, A. Akhter. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7594 |
|
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 BroadbandPerformance). |
|
| |
| RFC 7595 | Guidelines and Registration Procedures for URI Schemes |
| |
|
|
This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of UniformResource Identifier (URI) schemes. It obsoletes RFC 4395. |
|
| |
| RFC 7596 | Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture |
| |
| Authors: | Y. Cui, Q. Sun, M. Boucadair, T. Tsou, Y. Lee, I. Farrer. |
| Date: | July 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7596 |
|
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. |
|
| |
| RFC 7597 | Mapping of Address and Port with Encapsulation (MAP-E) |
| |
| Authors: | O. Troan, Ed., W. Dec, X. Li, C. Bao, S. Matsushima, T. Murakami, T. Taylor, Ed.. |
| Date: | July 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7597 |
|
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. |
|
| |
| RFC 7598 | DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients |
| |
| Authors: | T. Mrugalski, O. Troan, I. Farrer, S. Perreault, W. Dec, C. Bao, L. Yeh, X. Deng. |
| Date: | July 2015 |
| Formats: | txt json html |
| Updated by: | RFC 8539 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7598 |
|
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. |
|
| |
| RFC 7599 | Mapping of Address and Port using Translation (MAP-T) |
| |
| Authors: | X. Li, C. Bao, W. Dec, Ed., O. Troan, S. Matsushima, T. Murakami. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7599 |
|
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. |
|
