The IETF Datatracker is the day-to-day front-end to the IETF database for people| datatracker.ietf.org
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.| IETF Datatracker
The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. [STANDARDS-TRACK]| IETF Datatracker
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. [STANDARDS-TRACK]| IETF Datatracker
This document describes the S/KEY* One-Time Password system as released for public use by Bellcore. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.| IETF Datatracker
This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952.| IETF Datatracker
This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. [STANDARDS-TRACK]| IETF Datatracker
There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK]| IETF Datatracker
This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]| IETF Datatracker
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. [STANDARDS-TRACK]| IETF Datatracker
This document specifies the Neighbor Discovery protocol for IP Version 6. [STANDARDS-TRACK]| IETF Datatracker
This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]| IETF Datatracker
This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]| IETF Datatracker
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism.| IETF Datatracker
This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset.| IETF Datatracker
This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK]| IETF Datatracker
UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo updates and replaces RFC 2044, in particular addressing the question of versions of the relevant standards. [STANDARDS-TRACK]| IETF Datatracker
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind| IETF Datatracker
This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.| IETF Datatracker
This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni).| IETF Datatracker
This document defines the IP header field, called the DS (for differentiated services) field. [STANDARDS-TRACK]| IETF Datatracker
In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]| IETF Datatracker
This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]| IETF Datatracker
This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.| IETF Datatracker
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.| IETF Datatracker
This note describes a simple out-of-band protocol to ease setup of the Resource Public Key Infrastructure (RPKI) provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication. This setup protocol is not part of the provisioning or publication protocol; rather, it is intended to simplify configuration of these pr...| IETF Datatracker
This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. Even in cases where a certificate issuer runs its own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol whi...| IETF Datatracker
This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. This memo documents an Internet Best Current Practice.| IETF Datatracker
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). [STANDARDS-TRACK]| IETF Datatracker
This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard.| IETF Datatracker
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Activities Board (IAB). This memo provides information for the Internet community. It does not specify an Internet standard.| IETF Datatracker
This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). This memo provides information for the Internet community. It does not specifiy an Internet standard.| IETF Datatracker
This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. This is a revision of RFC 1120.| IETF Datatracker
This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]| IETF Datatracker
This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community. Distribution of this memo is unlimited.| IETF Datatracker
This document describe a widely deployed hybrid key exchange method in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512.| IETF Datatracker
This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on the quantum-resistant the Module-Lattice- Based Key-Encapsulation Mechanism (ML-KEM) standard and traditional Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes. These methods are defined for use in the SSH Transport Layer Protocol.| IETF Datatracker
Supply Chain Integrity, Transparency, and Trust (scitt)| datatracker.ietf.org
RFC| datatracker.ietf.org
This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]| IETF Datatracker
This document has been reviewed by the Federal Engineering Task Force (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. This RFC suggests an...| IETF Datatracker
This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for the Internet. This is an "idea" paper and discussion is strongly encouraged. This memo provides information for the Internet community. It does not specify an Internet standard.| IETF Datatracker
This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement. This RFC does not specify a standard.| IETF Datatracker
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. [STANDARDS-TRACK]| IETF Datatracker
This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807.| IETF Datatracker
The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.| IETF Datatracker
This document directs the IANA to designate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast address space for Private Use.| IETF Datatracker
This memo reclassifies the address block 240.0.0.0/4 as usable address space. While the community has not concluded whether the block should be considered public or private, given the current consumption rate, it is clear that the block should not be left unused. This document also makes several recommendations on ways that current implementations of the IP protocol stack will need to be modified to make this address space usable.| IETF Datatracker
This document redesignates 240/4, the region of the IPv4 address space historically known as "Experimental," "Future Use," or "Class E" address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet.| IETF Datatracker
This document provides definitions and an overview of the System for Cross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements.| IETF Datatracker
This memo describes common vulnerabilities related to Domain Name System (DNS) resource record (RR) processing as seen in several DNS client implementations. These vulnerabilities may lead to successful Denial-of-Service and Remote Code Execution attacks against the affected software. Where applicable, violations of RFC 1035 are mentioned.| IETF Datatracker
This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard. The Quote of the Day service simply sends a short message without regard to the input.| IETF Datatracker
The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.| IETF Datatracker
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.| IETF Datatracker
This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]| IETF Datatracker
This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.| IETF Datatracker
We present the set of protocols and procedures that constitute Inter- Domain Policy Routing (IDPR). [STANDARDS-TRACK]| IETF Datatracker
This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A). This memo provides information for the Internet community. It does not specify an Internet standard.| IETF Datatracker
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.| IETF Datatracker
This memo describes a method of encapsulating IPX datagrams within UDP packets so that IPX traffic can travel across an IP internet. [STANDARDS-TRACK] This memo defines objects for managing DS1 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]| IETF Datatracker
This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets. This technique is an Experimental Protocol for the Internet community. It does not specify an Internet standard.| IETF Datatracker
This RFC describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links. The motivation, implementation and performance of the method are described. C code for a sample implementation is given for reference. [STANDARDS-TRACK]| IETF Datatracker
This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]| IETF Datatracker
This document discusses the evaluation criteria for an Internet Standard Data Link Layer protocol to be used with point-to-point links. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.| IETF Datatracker
The Simple Network Management Protocol (SNMP) specification [1] allows for the protection of network management operations by a variety of security protocols. The SNMP administrative model described in [2] provides a framework for securing SNMP network management. In the context of that framework, this memo defines protocols to support the following three security services: data integrity, data origin authentication and data confidentiality. [STANDARDS-TRACK]| IETF Datatracker
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This memo is a status report on the parameters (i.e., numbers and keywords) used in protocols in the Internet community.| IETF Datatracker
This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. [STANDARDS-TRACK]| IETF Datatracker
This memo specifies the Point-to-Point Protocol (PPP) Initial Configuration Options as a Proposed Standard Protocol for the Internet community. When it becomes a full Standard, this protocol will be recommended for all TCP/IP implementations that communicate over serial links.| IETF Datatracker
This document describes three types of service in support of Internet Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- revocation list (CRL) storage, and CRL retrieval. [STANDARDS-TRACK]| IETF Datatracker
This is one of a series of documents defining privacy enhancement mechanisms for electronic mail transferred using Internet mail protocols. [STANDARDS-TRACK]| IETF Datatracker
This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK]| IETF Datatracker
This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail (PEM) in the Internet community. [STANDARDS-TRACK]| IETF Datatracker
This memo specifies the general form for Telnet options and the directions for their specification. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651, NIC 18640.| IETF Datatracker
This is the specification of the Telnet protocol used for remote terminal access in the ARPA Internet. The purpose of the TELNET Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (d...| IETF Datatracker
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. [STANDARDS-TRACK]| IETF Datatracker
This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.| IETF Datatracker
The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.| IETF Datatracker
This document describes the MD4 message-digest algorithm [1]. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard.| IETF Datatracker
This RFC provides definitions, references, and citations for algorithms, usage modes, and associated identifiers used in RFC-1113 and RFC-1114 in support of privacy-enhanced electronic mail. [STANDARDS-TRACK]| IETF Datatracker
This RFC specifies the key management aspects of Privacy Enhanced Mail. [STANDARDS-TRACK]| IETF Datatracker
This RFC specifies features for private electronic mail based on encryption technology. [STANDARDS-TRACK]| IETF Datatracker
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]| IETF Datatracker
Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significan...| IETF Datatracker
This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. [STANDARDS-TRACK]| IETF Datatracker
This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP). NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and a...| IETF Datatracker
This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format.| IETF Datatracker
This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. This RFC will be updated periodically, and in any case current information can be obtained from Joyce Reynolds. The assignment of numbers is also handled by Joyce. If you are developing a protocol or application that will require the use of a link, socket, port, protocol, network number, etc., please contact Joyce to receive a number ...| IETF Datatracker
Several sites now contain a complex of local links connected to the Internet via a gateway. The details of the internal connectivity are of little interest to the rest of the Internet. One way of organizing these local complexes of links is to use the same strategy as the Internet uses to organize networks, that is, to declare each link to be an entity (like a network) and to interconnect the links with devices that perform routing functions (like gateways). This general scheme is called subn...| IETF Datatracker
The problem of treating a set of local area networks (LANs) as one Internet network has generated some interest and concern. It is inappropriate to give each LAN within an site a distinct Internet network number. It is desirable to hide the details of the interconnections between the LANs within an site from people, gateways, and hosts outside the site. The question arises on how to best do this, and even how to do it at all. In RFC-917 Jeffery Mogul makes a case for the use of "explicit subn...| IETF Datatracker
This RFC proposes simple rules for broadcasting Internet datagrams on local networks that support broadcast, for addressing broadcasts, and for how gateways should handle them. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.| IETF Datatracker
This memo discusses subnets and proposes procedures for the use of subnets, including approaches to solving the problems that arise, particularly that of routing. A subnet of an Internet network is a logically visible sub-section of a single Internet network. For administrative or technical reasons, many organizations have chosen to divide one Internet network into several subnets, instead of acquiring a set of Internet network numbers. This RFC suggests a proposed protocol for the ARPA-Inter...| IETF Datatracker
This RFC suggests a method for workstations to dynamically find their protocol address (e.g., their Internet Address), when they know only their hardware address (e.g., their attached physical network address). This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements.| IETF Datatracker
This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This...| IETF Datatracker
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).| IETF Datatracker
This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous s...| IETF Datatracker
This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]| IETF Datatracker
To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document ...| IETF Datatracker
This document describes the global and other specialized IPv4 address blocks that have been assigned by the IANA. It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers.| IETF Datatracker
This memo provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.| IETF Datatracker
This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. [STANDARDS-TRACK]| IETF Datatracker
