IETF-Announce List
New RFCs
New and Revived Drafts
- Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS (draft-dgr-dprive-dtls-and-tls-profiles)
By Sara Dickinson, Daniel Kahn Gillmor, Tirumaleswar Reddy, 2015-12-23 TXT HTML PDF
Abstract: This document describes how a DNS client can use a domain name to authenticate a DNS server that uses Transport Layer Security (TLS) and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles for DNS clients and servers implementing DNS-over-TLS and DNS-over- DTLS.
- The 'XML2RFC' version 3 Vocabulary (draft-iab-xml2rfc)
By Paul Hoffman, 2015-12-23 TXT HTML PDF
Abstract: This document defines the "XML2RFC" version 3 vocabulary; an XML- based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 2629 and its expected followup, draft-iab-xml2rfc.
- Syntactic and Semantic Checks for Domain Validation Certificates (draft-kent-trans-domain-validation-cert-checks)
By Stephen Kent, Rick Andrews, 2015-12-23 TXT HTML PDF
Abstract: Certificate Transparency (CT) [RFC6962-bis] is a system for publicly logging the existence of X.509 certificates as they are issued or observed. The logging mechanism allows anyone to audit certification authority (CA) activity and detect the issuance of "suspect" certificates. Detecting mis-issuance of certificates is a primary goal of CT.
- Syntactic and Semantic Checks for Extended Validation Certificates (draft-kent-trans-extended-validation-cert-checks)
By Stephen Kent, Rick Andrews, 2015-12-23 TXT HTML PDF
Abstract: Certificate Transparency (CT) [RFC6962-bis] is a system for publicly logging the existence of X.509 certificates as they are issued or observed. The logging mechanism allows anyone to audit certification authority (CA) activity and detect the issuance of "suspect" certificates. Detecting mis-issuance of certificates is a primary goal of CT.
Updated Drafts
- A General Mechanism for RTP Header Extensions (draft-ietf-avtcore-rfc5285-bis)
By Roni Even, David Singer, HariKishan Desineni, 2015-12-23 TXT HTML PDF
Abstract: This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session.
- An Architecture for the Interface to the Routing System (draft-ietf-i2rs-architecture)
By Alia Atlas, Joel Halpern, Susan Hares, David Ward, Tom Nadeau, 2015-12-23 TXT HTML PDF
Abstract: This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of the Interface to Routing System (I2RS).
- JWS Unencoded Payload Option (draft-ietf-jose-jws-signing-input-options)
By Michael Jones, 2015-12-23 TXT HTML PDF
Abstract: JSON Web Signature (JWS) represents the payload of a JWS as a base64url encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.
- Proxy Mobile IPv6 Extensions to Support Flow Mobility (draft-ietf-netext-pmipv6-flowmob)
By Carlos Bernardos, 2015-12-23 TXT HTML PDF
Abstract: Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces.
- OSPF Topology-Transparent Zone (draft-ietf-ospf-ttz)
By Huaimo Chen, Renwei Li, Alvaro Retana, Yi Yang, Vic Liu, Mehmet Toy, 2015-12-23 TXT HTML PDF
Abstract: This document presents a topology-transparent zone in a domain. A topology-transparent zone comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. The information about the links and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a link down inside the zone is not seen by any router outside of the zone.
- RADIUS Attribute for MAP (draft-ietf-softwire-map-radius)
By Sheng Jiang, Yu Fu, Bing Liu, Peter Deacon, 2015-12-23 TXT HTML PDF
Abstract: Mapping of Address and Port (MAP) is a stateless mechanism for running IPv4 over IPv6-only infrastructure. It provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) MAP options has been defined to configure MAP Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCPv6 protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries MAP configuration information from AAA server to BNG. The MAP RADIUS attribute are designed following the simplify principle. It provides just enough information to form the correspondent DHCPv6 MAP option.
- Transport Layer Security (TLS) Cached Information Extension (draft-ietf-tls-cached-info)
By Stefan Santesson, Hannes Tschofenig, 2015-12-23 TXT HTML PDF
Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).
- A YANG Data Model for DHCP Configuration (draft-liu-dhc-dhcp-yang-model)
By Bing Liu, Kunkun Lou, 2015-12-23 TXT HTML PDF
Abstract: This document defines a YANG data model for configuring DHCP Server, relay, and client.
- Verification Extension for the Extensible Provisioning Protocol (EPP) Domain Name Mapping (draft-wang-eppext-domain-verification)
By Wang Wei, Linlin Zhou, Di Ma, Ning, XiaoDong Lee, Jim Galvin, 2015-12-23 TXT HTML PDF
Abstract: This mapping describes an verification extension to EPP domain name mapping [RFC5731]. Specified in Extensible Markup Language (XML), this extended mapping is applied to provide additional features required for the provisioning of domain verification.
- Verification Extension for the Extensible Provisioning Protocol (EPP) Contact Mapping (draft-zhou-eppext-contact-verification)
By Linlin Zhou, Di Ma, Wang Wei, Ning, XiaoDong Lee, Jim Galvin, 2015-12-23 TXT HTML PDF
Abstract: This mapping describes an verification extension to EPP contact mapping [RFC5733]. Specified in Extensible Markup Language (XML), this extended mapping is applied to provide additional features required for the provisioning of contact verification.
Expired Drafts
- OSPF Extensions for Flow Specification (draft-ietf-ospf-flowspec-extensions)
By Qiandeng Liang, Jianjie You, Nan Wu, Peng Fan, Keyur Patel, Acee Lindem, 2015-06-21 TXT HTML PDF
Abstract: Dissemination of the Traffic flow information was first introduced in the BGP protocol [RFC5575]. FlowSpec routes are used to distribute traffic filtering rules that are used to filter Denial-of-Service (DoS) attacks. For the networks that only deploy an IGP (Interior Gateway Protocol) (e.g., OSPF), it is required that the IGP is extended to distribute Flow Specification or FlowSpec routes.
|
Drafts Sent to IESG
IESG Progress
- Explicit RPF Vector (draft-ietf-pim-explicit-rpf-vector): In Last Call » IESG Evaluation
By Javed Asghar, IJsbrand Wijnands, Sowmya Krishnaswamy, Apoorva Karan, Vishal Arya, 2015-11-17 TXT HTML PDF
Abstract: The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the Source or RP associated with the multicast tree.
- SCTP-PF: Quick Failover Algorithm in SCTP (draft-ietf-tsvwg-sctp-failover): In Last Call » Waiting for Writeup
By Yoshifumi Nishida, Preethi Natarajan, Armando Caro, Paul Amer, Karen E. E. Nielsen, 2015-12-09 TXT HTML PDF
Abstract: SCTP supports multi-homing. However, when the failover operation specified in RFC4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. To overcome this problem this document specifies a quick failover algorithm (SCTP-PF) based on the introduction of a Potentially Failed (PF) state in SCTP Path Management.
Drafts Sent to RFC Editor
Other Status Changes
- The 'XML2RFC' version 3 Vocabulary (draft-hoffman-xml2rfc): Active » Replaced by draft-iab-xml2rfc
By Paul Hoffman, 2015-09-04 TXT HTML PDF
Abstract: This document defines the "XML2RFC" version 3 vocabulary; an XML- based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 2629 and its expected followup, draft-iab-xml2rfc.
- draft-ietf-kitten-aes-cbc-hmac-sha2: Expired » Replaced by draft-ietf-kitten-aes-cts-hmac-sha2
No title available; expired document? TXT HTML PDF
- draft-jain-kitten-krb-auth-indicator: Expired » Replaced by draft-ietf-kitten-krb-auth-indicator
No title available; expired document? TXT HTML PDF
RFC Editor Status Changes
- Elliptic Curves for Security (draft-irtf-cfrg-curves): » AUTH48
By Adam Langley, Mike Hamburg, spt, 2015-10-09 TXT HTML PDF
Abstract: This memo specifies two elliptic curves over prime fields that offer high practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.
IPR Disclosures
IESG/IAB/IAOC/Trust Minutes
Liaison Statements
Classified Ads
|