| |
| RFC 5901 | Extensions to the IODEF-Document Class for Reporting Phishing |
| |
| Authors: | P. Cain, D. Jevans. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5901 |
|
This document extends the Incident Object Description Exchange Format(IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents. |
|
| |
| RFC 5902 | IAB Thoughts on IPv6 Network Address Translation |
| |
| Authors: | D. Thaler, L. Zhang, G. Lebovitz. |
| Date: | July 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5902 |
|
There has been much recent discussion on the topic of whether theIETF should develop standards for IPv6 Network Address Translators(NATs). This document articulates the architectural issues raised byIPv6 NATs, the pros and cons of having IPv6 NATs, and provides theIAB's thoughts on the current open issues and the solution space. |
|
| |
| RFC 5903 | Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2 |
| |
|
|
This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet KeyExchange version 2 (IKEv2) protocols in addition to previously defined groups. These groups are based on modular arithmetic rather than binary arithmetic. These groups are defined to align IKE andIKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This document obsoletes RFC 4753. |
|
| |
| RFC 5904 | RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support |
| |
| Authors: | G. Zorn. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5904 |
|
This document defines a set of Remote Authentication Dial-In UserService (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. |
|
| |
| RFC 5905 | Network Time Protocol Version 4: Protocol and Algorithms Specification |
| |
|
|
The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol.NTPv4 includes a modified protocol header to accommodate the InternetProtocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. |
|
| |
| RFC 5906 | Network Time Protocol Version 4: Autokey Specification |
| |
| Authors: | B. Haberman, Ed., D. Mills. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5906 |
|
This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition,Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.
This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual MemorySystem (VMS) operating systems at http://www.ntp.org. |
|
| |
| RFC 5907 | Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) |
| |
| Authors: | H. Gerstung, C. Elliott, B. Haberman, Ed.. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5907 |
|
The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment. As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent. This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort. |
|
| |
| RFC 5908 | Network Time Protocol (NTP) Server Option for DHCPv6 |
| |
| Authors: | R. Gayraud, B. Lourdelet. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5908 |
|
The NTP Server Option for Dynamic Host Configuration Protocol forIPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts. |
|
| |
| RFC 5909 | Securing Neighbor Discovery Proxy: Problem Statement |
| |
| Authors: | J-M. Combes, S. Krishnan, G. Daley. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5909 |
|
Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.
Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a MobileNode is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.
Neighbor Discovery Proxy currently cannot be secured using SecureNeighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND. |
|
| |
| RFC 5910 | Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain NameSystem security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310. |
|
| |
| RFC 5911 | New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME |
| |
|
|
The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates thoseASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. |
|
| |
| RFC 5912 | New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) |
| |
|
|
The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The currentASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1.There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. |
|
| |
| RFC 5913 | Clearance Attribute and Authority Clearance Constraints Certificate Extension |
| |
| Authors: | S. Turner, S. Chokhani. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5913 |
|
This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate.The Authority Clearance Constraints certificate extension values in aTrust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject. |
|
| |
| RFC 5914 | Trust Anchor Format |
| |
| Authors: | R. Housley, S. Ashmore, C. Wallace. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5914 |
|
This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in TrustAnchor Management Requirements. |
|
| |
| RFC 5915 | Elliptic Curve Private Key Structure |
| |
| Authors: | S. Turner, D. Brown. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5915 |
|
This document specifies the syntax and semantics for conveyingElliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). |
|
| |
| RFC 5916 | Device Owner Attribute |
| |
| Authors: | S. Turner. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5916 |
|
This document defines the Device Owner attribute. It indicates the entity (e.g., company, organization, department, agency) that owns the device. This attribute may be included in public key certificates and attribute certificates. |
|
| |
| RFC 5917 | Clearance Sponsor Attribute |
| |
| Authors: | S. Turner. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5917 |
|
This document defines the clearance sponsor attribute. It indicates the entity that sponsored (i.e., granted) the clearance. This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute. |
|
| |
| RFC 5918 | Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) |
| |
| Authors: | R. Asati, I. Minei, B. Thomas. |
| Date: | August 2010 |
| Formats: | txt html json |
| Updated by: | RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5918 |
|
The Label Distribution Protocol (LDP) specification for the WildcardForward Equivalence Class (FEC) element has several limitations.This document addresses those limitations by defining a TypedWildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility. |
|
| |
| RFC 5919 | Signaling LDP Label Advertisement Completion |
| |
| Authors: | R. Asati, P. Mohapatra, E. Chen, B. Thomas. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5919 |
|
There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. |
|
| |
| RFC 5920 | Security Framework for MPLS and GMPLS Networks |
| |
| Authors: | L. Fang, Ed.. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5920 |
|
This document provides a security framework for Multiprotocol LabelSwitching (MPLS) and Generalized Multiprotocol Label Switching(GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizesRSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintainingMPLS and GMPLS networks across different domains or differentService Providers. |
|
| |
| RFC 5921 | A Framework for MPLS in Transport Networks |
| |
| Authors: | M. Bocci, Ed., S. Bryant, Ed., D. Frost, Ed., L. Levrau, L. Berger. |
| Date: | July 2010 |
| Formats: | txt html json |
| Updated by: | RFC 6215, RFC 7274 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5921 |
|
This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance(OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of theMPLS-TP.
This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
|
| |
| RFC 5922 | Domain Certificates in the Session Initiation Protocol (SIP) |
| |
| Authors: | V. Gurbani, S. Lawrence, A. Jeffrey. |
| Date: | June 2010 |
| Formats: | txt json html |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5922 |
|
This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure usingX.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of aSIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates. |
|
| |
| RFC 5923 | Connection Reuse in the Session Initiation Protocol (SIP) |
| |
| Authors: | V. Gurbani, Ed., R. Mahy, B. Tate. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5923 |
|
This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TransportLayer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control TransmissionProtocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. |
|
| |
| RFC 5924 | Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates |
| |
| Authors: | S. Lawrence, V. Gurbani. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5924 |
|
This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. |
|
| |
| RFC 5925 | The TCP Authentication Option |
| |
| Authors: | J. Touch, A. Mankin, R. Bonica. |
| Date: | June 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 2385 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5925 |
|
This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a staticMaster Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinatesMKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. |
|
| |
| RFC 5926 | Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) |
| |
| Authors: | G. Lebovitz, E. Rescorla. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5926 |
|
The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). |
|
| |
| RFC 5927 | ICMP Attacks against TCP |
| |
| Authors: | F. Gont. |
| Date: | July 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5927 |
|
This document discusses the use of the Internet Control MessageProtocol (ICMP) to perform a variety of attacks against theTransmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. |
|
| |
| RFC 5928 | Traversal Using Relays around NAT (TURN) Resolution Mechanism |
| |
|
|
This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a TraversalUsing Relays around NAT (TURN) allocation. |
|
| |
| RFC 5929 | Channel Bindings for TLS |
| |
| Authors: | J. Altman, N. Williams, L. Zhu. |
| Date: | July 2010 |
| Formats: | txt html json |
| Updated by: | RFC 9266 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5929 |
|
This document defines three channel binding types for Transport LayerSecurity (TLS), tls-unique, tls-server-end-point, and tls-unique-for- telnet, in accordance with RFC 5056 (On Channel Binding).
Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. |
|
| |
| RFC 5930 | Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol |
| |
| Authors: | S. Shen, Y. Mao, NSS. Murthy. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5930 |
|
This document describes the usage of Advanced Encryption StandardCounter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. |
|
| |
| RFC 5931 | Extensible Authentication Protocol (EAP) Authentication Using Only a Password |
| |
|
|
This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication.The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack. |
|
| |
| RFC 5932 | Camellia Cipher Suites for TLS |
| |
| Authors: | A. Kato, M. Kanda, S. Kanno. |
| Date: | June 2010 |
| Formats: | txt json html |
| Obsoletes: | RFC 4132 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5932 |
|
This document specifies a set of cipher suites for the TransportSecurity Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the cipher suites originally specified in RFC 4132 by introducing counterparts using the newer cryptographic hash algorithms from the SHA-2 family. This document obsoletes RFC 4132. |
|
| |
| RFC 5933 | Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
| Authors: | V. Dolmatov, Ed., A. Chuprina, I. Ustinov. |
| Date: | July 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6944 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5933 |
|
This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the DomainName System Security Extensions (DNSSEC). |
|
| |
| RFC 5934 | Trust Anchor Management Protocol (TAMP) |
| |
| Authors: | R. Housley, S. Ashmore, C. Wallace. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5934 |
|
This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store. The protocol makes use of the CryptographicMessage Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects. |
|
| |
| RFC 5935 | Expressing SNMP SMI Datatypes in XML Schema Definition Language |
| |
| Authors: | M. Ellison, B. Natale. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5935 |
|
This memo defines the IETF standard expression of Structure ofManagement Information (SMI) base datatypes in XML Schema Definition(XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. |
|
| |
| RFC 5936 | DNS Zone Transfer Protocol (AXFR) |
| |
|
|
The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.
The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. |
|
| |
| RFC 5937 | Using Trust Anchor Constraints during Certification Path Processing |
| |
| Authors: | S. Ashmore, C. Wallace. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5937 |
|
This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor.Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor. |
|
| |
| RFC 5938 | Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) |
| |
|
|
The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes anOPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions usingSession Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. |
|
| |
| RFC 5939 | Session Description Protocol (SDP) Capability Negotiation |
| |
|
|
The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.
The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.
The document defines a general SDP Capability Negotiation framework.It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. |
|
| |
| RFC 5940 | Additional Cryptographic Message Syntax (CMS) Revocation Information Choices |
| |
| Authors: | S. Turner, R. Housley. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5940 |
|
The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData,AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the CertificateRevocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol(OCSP) responses and Server-Based Certificate Validation Protocol(SCVP) requests and responses. |
|
| |
| RFC 5941 | Sharing Transaction Fraud Data |
| |
| Authors: | D. M'Raihi, S. Boeyen, M. Grandcolas, S. Bajaj. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5941 |
|
This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling WorkingGroup (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. |
|
| |
| RFC 5942 | IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes |
| |
| Authors: | H. Singh, W. Beebee, E. Nordmark. |
| Date: | July 2010 |
| Formats: | txt html json |
| Updates: | RFC 4861 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5942 |
|
IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861. |
|
| |
| RFC 5943 | A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing |
| |
| Authors: | B. Haberman, Ed.. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5943 |
|
The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a newRouting Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings). |
|
| |
| RFC 5944 | IP Mobility Support for IPv4, Revised |
| |
|
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 5945 | Resource Reservation Protocol (RSVP) Proxy Approaches |
| |
| Authors: | F. Le Faucheur, J. Manner, D. Wing, A. Guillou. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5945 |
|
The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable.This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described. |
|
| |
| RFC 5946 | Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy |
| |
| Authors: | F. Le Faucheur, J. Manner, A. Narayanan, A. Guillou, H. Malik. |
| Date: | October 2010 |
| Formats: | txt html json |
| Updates: | RFC 2205 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5946 |
|
Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows.With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP- capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to- end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP ReceiverProxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. |
|
| |
| RFC 5947 | Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Elwell, H. Kaplan. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5947 |
|
This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges(PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. |
|
| |
| RFC 5948 | Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16 |
| |
| Authors: | S. Madanapalli, S. Park, S. Chakrabarti, G. Montenegro. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5948 |
|
IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specificConvergence Sublayers for transmitting upper-layer protocols. ThePacket CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) andIEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 MediaAccess Control (MAC) layer.
This document specifies the frame format, the Maximum TransmissionUnit (MTU), and the address assignment procedures for transmittingIPv4 packets over the IP-specific part of the Packet ConvergenceSublayer of IEEE 802.16. |
|
| |
| RFC 5949 | Fast Handovers for Proxy Mobile IPv6 |
| |
| Authors: | H. Yokota, K. Chowdhury, R. Koodli, B. Patil, F. Xia. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5949 |
|
Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. WhileMIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6;RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6.
When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. |
|
| |
| RFC 5950 | Network Management Framework for MPLS-based Transport Networks |
| |
| Authors: | S. Mansfield, Ed., E. Gray, Ed., K. Lam, Ed.. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5950 |
|
This document provides the network management framework for theTransport Profile for Multi-Protocol Label Switching (MPLS-TP).
This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network.
The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. |
|
| |
| RFC 5951 | Network Management Requirements for MPLS-based Transport Networks |
| |
| Authors: | K. Lam, S. Mansfield, E. Gray. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5951 |
|
This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile(MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLSTransport Profile is constructed. That is, these requirements indicate what management capabilities need to be available inMPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. |
|
| |
| RFC 5952 | A Recommendation for IPv6 Address Text Representation |
| |
| Authors: | S. Kawamura, M. Kawashima. |
| Date: | August 2010 |
| Formats: | txt html json |
| Updates: | RFC 4291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5952 |
|
As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. |
|
| |
| RFC 5953 | Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), that uses either the Transport LayerSecurity protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of aSNMP Transport Subsystem to make this protection possible in an interoperable way.
This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use ofTCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.
This document also defines a portion of the Management InformationBase (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. |
|
| |
| RFC 5954 | Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261 |
| |
| Authors: | V. Gurbani, Ed., B. Carpenter, Ed., B. Tate, Ed.. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5954 |
|
This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261.It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. |
|
| |
| RFC 5955 | The application/timestamped-data Media Type |
| |
|
|
This document defines a new media type for TimeStampedData envelopes as described in RFC 5544. |
|
| |
| RFC 5956 | Forward Error Correction Grouping Semantics in the Session Description Protocol |
| |
|
|
This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in theSession Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888).These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (SynchronizationSource) grouping semantics are also defined in this document forReal-time Transport Protocol (RTP) streams using SSRC multiplexing. |
|
| |
| RFC 5957 | Display-Based Address Sorting for the IMAP4 SORT Extension |
| |
|
|
This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields. |
|
| |
| RFC 5958 | Asymmetric Key Packages |
| |
|
|
This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. TheCryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC5208. |
|
| |
| RFC 5959 | Algorithms for Asymmetric Key Package Content Type |
| |
|
|
This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958. It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData,EnvelopedData, EncryptedData, AuthenticatedData, andAuthEnvelopedData. |
|
| |
| RFC 5960 | MPLS Transport Profile Data Plane Architecture |
| |
| Authors: | D. Frost, Ed., S. Bryant, Ed., M. Bocci, Ed.. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5960 |
|
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network. |
|
| |
| RFC 5961 | Improving TCP's Robustness to Blind In-Window Attacks |
| |
| Authors: | A. Ramaiah, R. Stewart, M. Dalal. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updated by: | RFC 9293 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5961 |
|
TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 orBorder Gateway Protocol (BGP) [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks.
Many of these long-term TCP applications tend to have predictable IP addresses and ports that makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in RFC 793) to be guessed.Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. |
|
| |
| RFC 5962 | Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) |
| |
| Authors: | H. Schulzrinne, V. Singh, H. Tschofenig, M. Thomson. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5962 |
|
The Geopriv Location Object introduced by the Presence InformationData Format - Location Object (PIDF-LO), RFC 4119, defines a basicXML format for carrying geographical information of a presentity.This document defines PIDF-LO extensions to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity. |
|
| |
| RFC 5963 | IPv6 Deployment in Internet Exchange Points (IXPs) |
| |
| Authors: | R. Gagliano. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5963 |
|
This document provides guidance on IPv6 deployment in InternetExchange Points (IXPs). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4. |
|
| |
| RFC 5964 | Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries |
| |
| Authors: | J. Winterbottom, M. Thomson. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5964 |
|
This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a Location-to-Service Translation (LoST) server, is described. |
|
| |
| RFC 5965 | An Extensible Format for Email Feedback Reports |
| |
| Authors: | Y. Shafranovich, J. Levine, M. Kucherawy. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6650 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5965 |
|
This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used inInternet email. |
|
| |
| RFC 5966 | DNS Transport over TCP - Implementation Requirements |
| |
|
|
This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. |
|
| |
| RFC 5967 | The application/pkcs10 Media Type |
| |
|
|
This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986. |
|
| |
| RFC 5968 | Guidelines for Extending the RTP Control Protocol (RTCP) |
| |
| Authors: | J. Ott, C. Perkins. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5968 |
|
The RTP Control Protocol (RTCP) is used along with the Real-timeTransport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. |
|
| |
| RFC 5969 | IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification |
| |
| Authors: | W. Townsley, O. Troan. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5969 |
|
This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism. |
|
| |
| RFC 5970 | DHCPv6 Options for Network Boot |
| |
| Authors: | T. Huth, J. Freimann, V. Zimmer, D. Thaler. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5970 |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network. |
|
| |
| RFC 5971 | GIST: General Internet Signalling Transport |
| |
| Authors: | H. Schulzrinne, R. Hancock. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5971 |
|
This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General InternetSignalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework. |
|
| |
| RFC 5972 | General Internet Signaling Transport (GIST) State Machine |
| |
| Authors: | T. Tsenov, H. Tschofenig, X. Fu, Ed., C. Aoun, E. Davies. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5972 |
|
This document describes state machines for the General InternetSignaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate howGIST may be implemented. |
|
| |
| RFC 5973 | NAT/Firewall NSIS Signaling Layer Protocol (NSLP) |
| |
| Authors: | M. Stiemerling, H. Tschofenig, C. Aoun, E. Davies. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5973 |
|
This memo defines the NSIS Signaling Layer Protocol (NSLP) forNetwork Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. |
|
| |
| RFC 5974 | NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling |
| |
| Authors: | J. Manner, G. Karagiannis, A. McDonald. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5974 |
|
This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet.It is in accordance with the framework and requirements developed inNSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, describes the design decisions made, and provides examples. It specifies object, message formats, and processing rules. |
|
| |
| RFC 5975 | QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP) |
| |
| Authors: | G. Ash, Ed., A. Bader, Ed., C. Kappler, Ed., D. Oran, Ed.. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5975 |
|
The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC.This document defines a template for the QSPEC including a number ofQSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in theQSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. |
|
| |
| RFC 5976 | Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes |
| |
| Authors: | G. Ash, A. Morton, M. Dolly, P. Tarapore, C. Dvorak, Y. El Mghazli. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5976 |
|
This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. Y.1541 specifies 8 classes of NetworkPerformance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. |
|
| |
| RFC 5977 | RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv |
| |
| Authors: | A. Bader, L. Westberg, G. Karagiannis, C. Kappler, T. Phelan. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5977 |
|
This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management inDiffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination.In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes. |
|
| |
| RFC 5978 | Using and Extending the NSIS Protocol Family |
| |
| Authors: | J. Manner, R. Bless, J. Loughney, E. Davies, Ed.. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5978 |
|
This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010. It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. |
|
| |
| RFC 5979 | NSIS Operation over IP Tunnels |
| |
| Authors: | C. Shen, H. Schulzrinne, S. Lee, J. Bang. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5979 |
|
NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to correspondingQoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments. |
|
| |
| RFC 5980 | NSIS Protocol Operation in Mobile Environments |
| |
| Authors: | T. Sanda, Ed., X. Fu, S. Jeong, J. Manner, H. Tschofenig. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5980 |
|
Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols. |
|
| |
| RFC 5981 | Authorization for NSIS Signaling Layer Protocols |
| |
| Authors: | J. Manner, M. Stiemerling, H. Tschofenig, R. Bless, Ed.. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5981 |
|
Signaling layer protocols specified within the Next Steps inSignaling (NSIS) framework may rely on the General Internet SignalingTransport (GIST) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This document presents a generic model and object formats for session authorization within theNSIS signaling layer protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. |
|
| |
| RFC 5982 | IP Flow Information Export (IPFIX) Mediation: Problem Statement |
| |
| Authors: | A. Kobayashi, Ed., B. Claise, Ed.. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5982 |
|
Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP FlowInformation Export (IPFIX) Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIXMediation applicability examples along with the problems. |
|
| |
| RFC 5983 | Mailing Lists and Internationalized Email Addresses |
| |
|
|
This document describes considerations for mailing lists with the introduction of internationalized email addresses.
This document makes some specific recommendations on how mailing lists should act in various situations. |
|
| |
| RFC 5984 | Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding |
| |
| Authors: | K-M. Moller. |
| Date: | 1 April 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5984 |
|
This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding. |
|
| |
| RFC 5985 | HTTP-Enabled Location Delivery (HELD) |
| |
|
|
This document defines a Layer 7 Location Configuration Protocol (L7LCP) and describes the use of HTTP and HTTP/TLS as transports for theL7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer. |
|
| |
| RFC 5986 | Discovering the Local Location Information Server (LIS) |
| |
| Authors: | M. Thomson, J. Winterbottom. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5986 |
|
Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. DynamicHost Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. |
|
| |
| RFC 5987 | Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters |
| |
|
|
By default, message header field parameters in Hypertext TransferProtocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC2231. |
|
| |
| RFC 5988 | Web Linking |
| |
|
|
This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. |
|
| |
| RFC 5989 | A SIP Event Package for Subscribing to Changes to an HTTP Resource |
| |
| Authors: | A.B. Roach. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5989 |
|
The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol(HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near real- time, when a specific HTTP resource is created, changed, or deleted.This document proposes a mechanism, based on the SIP Event Framework, for doing so. |
|
| |
| RFC 5990 | Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | J. Randall, B. Kaliski, J. Brainard, S. Turner. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5990 |
|
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using theRSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax(CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44. |
|
| |
| RFC 5991 | Teredo Security Updates |
| |
| Authors: | D. Thaler, S. Krishnan, J. Hoagland. |
| Date: | September 2010 |
| Formats: | txt json html |
| Updates: | RFC 4380 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5991 |
|
The Teredo protocol defines a set of flags that are embedded in everyTeredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible. |
|
| |
| RFC 5992 | Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic |
| |
| Authors: | S. Sharikov, D. Miloshevic, J. Klensin. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5992 |
|
This document is a guideline for registries and registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Kildin Sami,Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone. It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations. |
|
| |
| RFC 5993 | RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR) |
| |
| Authors: | X. Duan, S. Wang, M. Westerlund, K. Hellwig, I. Johansson. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5993 |
|
This document specifies the payload format for packetization ofGlobal System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. |
|
| |
| RFC 5994 | Application of Ethernet Pseudowires to MPLS Transport Networks |
| |
| Authors: | S. Bryant, Ed., M. Morrow, G. Swallow, R. Cherukuri, T. Nadeau, N. Harrison, B. Niven-Jenkins. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5994 |
|
Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.
Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T.The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.
This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully- featured packet transport solution addressing all of the requirements of MPLS-TP. |
|
| |
| RFC 5995 | Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections |
| |
| Authors: | J. Reschke. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5995 |
|
The Hypertext Transfer Protocol (HTTP) Extensions for the WebDistributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST".
This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as theCalendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task.
This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. |
|
| |
| RFC 5996 | Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations(SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. |
|
| |
| RFC 5997 | Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol |
| |
|
|
This document describes a deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. |
|
| |
| RFC 5998 | An Extension for EAP-Only Authentication in IKEv2 |
| |
| Authors: | P. Eronen, H. Tschofenig, Y. Sheffer. |
| Date: | September 2010 |
| Formats: | txt json html |
| Updates: | RFC 5996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5998 |
|
IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards.
This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. |
|
