| |
| RFC 5601 | Pseudowire (PW) Management Information Base (MIB) |
| |
| Authors: | T. Nadeau, Ed., D. Zelig, Ed.. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5601 |
|
This memo defines a Standards Track portion of the ManagementInformation Base for use with network management protocols in theInternet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a generalPacket Switched Network. |
|
| |
| RFC 5602 | Pseudowire (PW) over MPLS PSN Management Information Base (MIB) |
| |
| Authors: | D. Zelig, Ed., T. Nadeau, Ed.. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5602 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a MIB module for PW operation overMultiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). |
|
| |
| RFC 5603 | Ethernet Pseudowire (PW) Management Information Base (MIB) |
| |
| Authors: | D. Zelig, Ed., T. Nadeau, Ed.. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5603 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling of Ethernet pseudowire (PW) services. |
|
| |
| RFC 5604 | Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) |
| |
| Authors: | O. Nicklass. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5604 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for pseudowire encapsulation for structured or unstructured Time-DivisionMultiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet SwitchedNetwork (PSN). |
|
| |
| RFC 5605 | Managed Objects for ATM over Packet Switched Networks (PSNs) |
| |
| Authors: | O. Nicklass, T. Nadeau. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5605 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling ATMPseudowire (PW) carrying ATM cells over Packet Switched Networks(PSNs). |
|
| |
| RFC 5606 | Implications of 'retransmission-allowed' for SIP Location Conveyance |
| |
| Authors: | J. Peterson, T. Hardie, J. Morris. |
| Date: | August 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5606 |
|
This document explores an ambiguity in the interpretation of the<retransmission-allowed&rt; element of the Presence Information DataFormat for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.
Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. |
|
| |
| RFC 5607 | Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management |
| |
| Authors: | D. Nelson, G. Weber. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5607 |
|
This document specifies Remote Authentication Dial-In User Service(RADIUS) attributes for authorizing management access to a NetworkAccess Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. |
|
| |
| RFC 5608 | Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models |
| |
| Authors: | K. Narayan, D. Nelson. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5608 |
|
This memo describes the use of a Remote Authentication Dial-In UserService (RADIUS) authentication and authorization service with SimpleNetwork Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model. |
|
| |
| RFC 5609 | State Machines for the Protocol for Carrying Authentication for Network Access (PANA) |
| |
| Authors: | V. Fajardo, Ed., Y. Ohba, R. Marin-Lopez. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5609 |
|
This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA). The state machines consist of the PANA Client (PaC) state machine and the PANAAuthentication Agent (PAA) state machine. The two state machines show how PANA can interface with the Extensible AuthenticationProtocol (EAP) state machines. The state machines and associated models are informative only. Implementations may achieve the same results using different methods. |
|
| |
| RFC 5610 | Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements |
| |
| Authors: | E. Boschi, B. Trammell, L. Mark, T. Zseby. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5610 |
|
This document describes an extension to the IP Flow InformationExport (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. |
|
| |
| RFC 5611 | Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires |
| |
| Authors: | A. Vainshtein, S. Galtzur. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5611 |
|
This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure- aware (Circuit Emulation Service over Packet Switched Network(CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires.Support of structure-aware (Time-Division Multiplexing over IP(TDMoIP) style) pseudowires over L2TPv3 is left for further study. |
|
| |
| RFC 5612 | Enterprise Number for Documentation Use |
| |
| Authors: | P. Eronen, D. Harrington. |
| Date: | August 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5612 |
|
This document describes an Enterprise Number (also known as SMINetwork Management Private Enterprise Code) for use in documentation. |
|
| |
| RFC 5613 | OSPF Link-Local Signaling |
| |
| Authors: | A. Zinin, A. Roy, L. Nguyen, B. Friedman, D. Yeung. |
| Date: | August 2009 |
| Formats: | txt json html |
| Obsoletes: | RFC 4813 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5613 |
|
OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well- defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track. |
|
| |
| RFC 5614 | Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding |
| |
|
|
This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANETDesignated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways.First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies.Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. |
|
| |
| RFC 5615 | H.248/MEGACO Registration Procedures |
| |
|
|
This document updates the H.248/MEGACO IANA Package registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. |
|
| |
| RFC 5616 | Streaming Internet Messaging Attachments |
| |
| Authors: | N. Cook. |
| Date: | August 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5616 |
|
This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from anIMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.
The document describes a profile for making use of the URLAUTH- authorized IMAP URLs (RFC 5092), the Network Announcement SIP MediaService (RFC 4240), and the Media Server Control Markup Language (RFC5022). |
|
| |
| RFC 5617 | DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) |
| |
| Authors: | E. Allman, J. Fenton, M. Delany, J. Levine. |
| Date: | August 2009 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5617 |
|
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email to permit verification of the source and contents of messages. This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether a domain signs its outgoing mail as well as how other hosts can access that record. |
|
| |
| RFC 5618 | Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) |
| |
|
|
This memo describes a simple extension to TWAMP (the Two-Way ActiveMeasurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. |
|
| |
| RFC 5619 | Softwire Security Analysis and Requirements |
| |
| Authors: | S. Yamamoto, C. Williams, H. Yokota, F. Parent. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5619 |
|
This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. |
|
| |
| RFC 5620 | RFC Editor Model (Version 1) |
| |
|
|
The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent SubmissionEditor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional)Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. |
|
| |
| RFC 5621 | Message Body Handling in the Session Initiation Protocol (SIP) |
| |
|
|
This document specifies how message bodies are handled in SIP.Additionally, this document specifies SIP user agent support for MIME(Multipurpose Internet Mail Extensions) in message bodies. |
|
| |
| RFC 5622 | Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) |
| |
|
|
This document specifies a profile for Congestion Control Identifier4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification(ECN), while minimizing abrupt rate changes. |
|
| |
| RFC 5623 | Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering |
| |
| Authors: | E. Oki, T. Takeda, JL. Le Roux, A. Farrel. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5623 |
|
A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. ThePath Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering.
This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual NetworkTopology Manager (VNTM). |
|
| |
| RFC 5624 | Quality of Service Parameters for Usage with Diameter |
| |
| Authors: | J. Korhonen, Ed., H. Tschofenig, E. Davies. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5624 |
|
This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.
The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per- hop behavior class object. |
|
| |
| RFC 5625 | DNS Proxy Implementation Guidelines |
| |
|
|
This document provides guidelines for the implementation of DNS proxies, as found in broadband gateways and other similar network devices. |
|
| |
| RFC 5626 | Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) |
| |
|
|
The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams toUser Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by theUser Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. |
|
| |
| RFC 5627 | Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5627 |
|
Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called aGlobally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. |
|
| |
| RFC 5628 | Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs) |
| |
| Authors: | P. Kyzivat. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5628 |
|
RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.
However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI(GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar. |
|
| |
| RFC 5629 | A Framework for Application Interaction in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5629 |
|
This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent (UA) to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi-Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. |
|
| |
| RFC 5630 | The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) |
| |
|
|
This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP).It also makes normative changes to SIP. |
|
| |
| RFC 5631 | Session Initiation Protocol (SIP) Session Mobility |
| |
| Authors: | R. Shacham, H. Schulzrinne, S. Thakolsri, W. Kellerer. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5631 |
|
Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP).Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is an informational document. |
|
| |
| RFC 5632 | Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial |
| |
| Authors: | C. Griffiths, J. Livingood, L. Popkin, R. Woundy, Y. Yang. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5632 |
|
This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a ProactiveNetwork Provider Participation for P2P (P4P) technical trial in July2008. This trial used P4P iTracker technology, which is being considered by the IETF as part of the Application Layer TransportOptimization (ALTO) working group. |
|
| |
| RFC 5633 | Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers |
| |
|
|
This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President. |
|
| |
| RFC 5634 | Quick-Start for the Datagram Congestion Control Protocol (DCCP) |
| |
| Authors: | G. Fairhurst, A. Sathiaseelan. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5634 |
|
This document specifies the use of the Quick-Start mechanism by theDatagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID3, and CCID 4. Quick-Start enables a DCCP sender to cooperate withQuick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the globalInternet. |
|
| |
| RFC 5635 | Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) |
| |
| Authors: | W. Kumari, D. McPherson. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5635 |
|
Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks.This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. |
|
| |
| RFC 5636 | Traceable Anonymous Certificate |
| |
| Authors: | S. Park, H. Park, Y. Won, J. Lee, S. Kent. |
| Date: | August 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5636 |
|
This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called TraceableAnonymous Certificates (TACs). |
|
| |
| RFC 5637 | Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6 |
| |
| Authors: | G. Giaretta, I. Guardini, E. Demaria, J. Bournelle, R. Lopez. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5637 |
|
In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, andAccounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. |
|
| |
| RFC 5638 | Simple SIP Usage Scenario for Applications in the Endpoints |
| |
| Authors: | H. Sinnreich, Ed., A. Johnston, E. Shim, K. Singh. |
| Date: | September 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5638 |
|
For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with richInternet applications (RIAs). Significant telephony features may also be implemented in the endpoints.
This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about11.
References for NAT traversal and for security are also provided. |
|
| |
| RFC 5639 | Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation |
| |
| Authors: | M. Lochter, J. Merkle. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5639 |
|
This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), TransportLayer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). |
|
| |
| RFC 5640 | Load-Balancing for Mesh Softwires |
| |
| Authors: | C. Filsfils, P. Mohapatra, C. Pignataro. |
| Date: | August 2009 |
| Formats: | txt json html |
| Updated by: | RFC 9012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5640 |
|
Payloads transported over a Softwire mesh service (as defined by BGPEncapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering theSoftwire can only be interpreted by the ingress and egress routers.Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two TunnelingProtocol - Version 3 (L2TPv3) over IP or Generic RoutingEncapsulation (GRE) encapsulation to what would be achieved without such encapsulation. |
|
| |
| RFC 5641 | Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values |
| |
|
|
This document defines additional Layer 2 Tunneling Protocol Version 3(L2TPv3) bit values to be used within the "Circuit Status" AttributeValue Pair (AVP) to communicate finer-grained error states forAttachment Circuits (ACs) and pseudowires (PWs). It also generalizes the Active bit and deprecates the use of the New bit in the CircuitStatus AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC4719. |
|
| |
| RFC 5642 | Dynamic Hostname Exchange Mechanism for OSPF |
| |
| Authors: | S. Venkata, S. Harwani, C. Pignataro, D. McPherson. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5642 |
|
This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS. This mechanism is applicable to both OSPFv2 and OSPFv3. |
|
| |
| RFC 5643 | Management Information Base for OSPFv3 |
| |
| Authors: | D. Joyal, Ed., V. Manral, Ed.. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5643 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets.In particular, it defines objects for managing the Open Shortest PathFirst (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). |
|
| |
| RFC 5644 | IP Performance Metrics (IPPM): Spatial and Multicast |
| |
| Authors: | E. Stephan, L. Liang, A. Morton. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5644 |
|
The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). |
|
| |
| RFC 5645 | Update to the Language Subtag Registry |
| |
| Authors: | D. Ewell, Ed.. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5645 |
|
This memo defines the procedure used to update the IANA LanguageSubtag Registry, in conjunction with the publication of RFC 5646, for use in forming tags for identifying languages. |
|
| |
| RFC 5646 | Tags for Identifying Languages |
| |
|
|
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. |
|
| |
| RFC 5647 | AES Galois Counter Mode for the Secure Shell Transport Layer Protocol |
| |
| Authors: | K. Igoe, J. Solinas. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5647 |
|
Secure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH TransportLayer Protocol. |
|
| |
| RFC 5648 | Multiple Care-of Addresses Registration |
| |
| Authors: | R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6089 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5648 |
|
According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (NetworkMobility) Basic Support protocol as well. |
|
| |
| RFC 5649 | Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm |
| |
| Authors: | R. Housley, M. Dworkin. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5649 |
|
This document specifies a padding convention for use with the AES KeyWrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of64 bits, allowing a key of any practical length to be wrapped. |
|
| |
| RFC 5650 | Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) |
| |
| Authors: | M. Morgenstern, S. Baillie, U. Bonollo. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5650 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the"Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing Asymmetric Digital SubscriberLine (ADSL), ADSL2, and ADSL2+ interfaces. |
|
| |
| RFC 5651 | Layered Coding Transport (LCT) Building Block |
| |
| Authors: | M. Luby, M. Watson, L. Vicisano. |
| Date: | October 2009 |
| Formats: | txt json html |
| Obsoletes: | RFC 3451 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5651 |
|
The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols usingIP multicast, but it also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This document obsoletes RFC 3451. |
|
| |
| RFC 5652 | Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. |
|
| |
| RFC 5653 | Generic Security Service API Version 2: Java Bindings Update |
| |
|
|
The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in"Generic Security Service API Version 2 : Java Bindings" (RFC 2853).This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience.
The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2,Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "TheKerberos Version 5 Generic Security Service Application ProgramInterface (GSS-API) Mechanism: Version 2" (RFC 4121). |
|
| |
| RFC 5654 | Requirements of an MPLS Transport Profile |
| |
| Authors: | B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., N. Sprecher, S. Ueno. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5654 |
|
This document specifies the requirements of an MPLS Transport Profile(MPLS-TP). This document is a product of a joint effort of theInternational Telecommunications Union (ITU) and IETF to include anMPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union -Telecommunications Standardization Sector (ITU-T).
This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.
The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. |
|
| |
| RFC 5655 | Specification of the IP Flow Information Export (IPFIX) File Format |
| |
| Authors: | B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5655 |
|
This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. |
|
| |
| RFC 5656 | Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer |
| |
| Authors: | D. Stebila, J. Green. |
| Date: | December 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5656 |
|
This document describes algorithms based on Elliptic CurveCryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman(ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. |
|
| |
| RFC 5657 | Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard |
| |
|
|
Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. |
|
| |
| RFC 5658 | Addressing Record-Route Issues in the Session Initiation Protocol (SIP) |
| |
| Authors: | T. Froment, C. Lebel, B. Bonnaerens. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5658 |
|
A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it.This header contains a SIP Uniform Resource Identifier (URI) or SIPS(secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy. These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp".When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only aRecord-Route rewriting solution. |
|
| |
| RFC 5659 | An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge |
| |
| Authors: | M. Bocci, S. Bryant. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5659 |
|
This document describes an architecture for extending pseudowire emulation across multiple packet switched network (PSN) segments.Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, as are other scenarios where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi- segment pseudowires, defines terminology, and specifies the various protocol elements and their functions. |
|
| |
| RFC 5660 | IPsec Channels: Connection Latching |
| |
| Authors: | N. Williams. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5660 |
|
This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec SecurityAssociation (SA) parameters for the lifetime of the connections.Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.
Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than NothingSecurity (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.
Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. |
|
| |
| RFC 5661 | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, DirectoryDelegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior toNFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. |
|
| |
| RFC 5662 | Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description |
| |
| Authors: | S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5662 |
|
This document provides the External Data Representation Standard(XDR) description for Network File System version 4 (NFSv4) minor version 1. |
|
| |
| RFC 5663 | Parallel NFS (pNFS) Block/Volume Layout |
| |
| Authors: | D. Black, S. Fridella, J. Glasgow. |
| Date: | January 2010 |
| Formats: | txt html json |
| Updated by: | RFC 6688 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5663 |
|
Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to allow clients to directly access file data on the storage used by theNFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage. |
|
| |
| RFC 5664 | Object-Based Parallel NFS (pNFS) Operations |
| |
| Authors: | B. Halevy, B. Welch, J. Zelenka. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5664 |
|
Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by theNFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. |
|
| |
| RFC 5665 | IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats |
| |
|
|
This document lists IANA Considerations for Remote Procedure Call(RPC) Network Identifiers (netids) and RPC Universal NetworkAddresses (uaddrs). This document updates, but does not replace, RFC1833. |
|
| |
| RFC 5666 | Remote Direct Memory Access Transport for Remote Procedure Call |
| |
| Authors: | T. Talpey, B. Callaghan. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8166 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5666 |
|
This document describes a protocol providing Remote Direct MemoryAccess (RDMA) as a new transport for Remote Procedure Call (RPC).The RDMA transport binding conveys the benefits of efficient, bulk- data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. |
|
| |
| RFC 5667 | Network File System (NFS) Direct Data Placement |
| |
| Authors: | T. Talpey, B. Callaghan. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8267 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5667 |
|
This document defines the bindings of the various Network File System(NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2,3, 4, and 4.1 over such an RDMA transport. |
|
| |
| RFC 5668 | 4-Octet AS Specific BGP Extended Community |
| |
| Authors: | Y. Rekhter, S. Sangli, D. Tappan. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5668 |
|
This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. |
|
| |
| RFC 5669 | The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) |
| |
| Authors: | S. Yoon, J. Kim, H. Park, H. Jeong, Y. Won. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5669 |
|
This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport ControlProtocol (RTCP). |
|
| |
| RFC 5670 | Metering and Marking Behaviour of PCN-Nodes |
| |
| Authors: | P. Eardley, Ed.. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5670 |
|
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allowsPCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. |
|
| |
| RFC 5671 | Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) |
| |
| Authors: | S. Yasukawa, A. Farrel, Ed.. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5671 |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) networks.
Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered(TE) Label Switched Paths (LSPs).
This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate. |
|
| |
| RFC 5672 | RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update |
| |
|
|
This document updates RFC 4871, "DomainKeys Identified Mail (DKIM)Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module.The Update is in the style of an Errata entry, albeit a rather long one. |
|
| |
| RFC 5673 | Industrial Routing Requirements in Low-Power and Lossy Networks |
| |
| Authors: | K. Pister, Ed., P. Thubert, Ed., S. Dwars, T. Phinney. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5673 |
|
The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices. |
|
| |
| RFC 5674 | Alarms in Syslog |
| |
| Authors: | S. Chisholm, R. Gerhards. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5674 |
|
This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. It also includes a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. |
|
| |
| RFC 5675 | Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages |
| |
| Authors: | V. Marinov, J. Schoenwaelder. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5675 |
|
This memo defines a mapping from Simple Network Management Protocol(SNMP) notifications to SYSLOG messages. |
|
| |
| RFC 5676 | Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications |
| |
| Authors: | J. Schoenwaelder, A. Clemm, A. Karmakar. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5676 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a mapping of SYSLOG messages to SimpleNetwork Management Protocol (SNMP) notifications. |
|
| |
| RFC 5677 | IEEE 802.21 Mobility Services Framework Design (MSFD) |
| |
| Authors: | T. Melia, Ed., G. Bajko, S. Das, N. Golmie, JC. Zuniga. |
| Date: | December 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5677 |
|
This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for MobilityServices (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server. Instead, it is assumed that either lower- layer (e.g., link-layer) security mechanisms or overall system- specific proprietary security solutions are used. |
|
| |
| RFC 5678 | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery |
| |
| Authors: | G. Bajko, S. Das. |
| Date: | December 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5678 |
|
This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS) (see RFC 5677). These Mobility Services are used to assist a mobile node (MN) in handover preparation(network discovery) and handover decision (network selection). The services addressed in this document are the Media IndependentHandover Services defined in IEEE 802.21. |
|
| |
| RFC 5679 | Locating IEEE 802.21 Mobility Services Using DNS |
| |
|
|
This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-definedMobility Services. Such Mobility Services are used to assist aMobile Node (MN) supporting IEEE 802.21, in handover preparation(network discovery) and handover decision (network selection). The services addressed by this document are the Media IndependentHandover Services defined in IEEE 802.21. |
|
| |
| RFC 5680 | The Nominating Committee Process: Open Disclosure of Willing Nominees |
| |
|
|
This document updates RFC 3777, Section 3, Bullet 6 to allow aNominating and Recall Committee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling. |
|
| |
| RFC 5681 | TCP Congestion Control |
| |
|
|
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. |
|
| |
| RFC 5682 | Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP |
| |
| Authors: | P. Sarolahti, M. Kojo, K. Yamamoto, M. Hata. |
| Date: | September 2009 |
| Formats: | txt html json |
| Updates: | RFC 4138 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5682 |
|
The purpose of this document is to move the F-RTO (ForwardRTO-Recovery) functionality for TCP in RFC 4138 fromExperimental to Standards Track status. The F-RTO support for StreamControl Transmission Protocol (SCTP) in RFC 4138 remains withExperimental status. See Appendix B for the differences between this document and RFC 4138.
Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. |
|
| |
| RFC 5683 | Password-Authenticated Key (PAK) Diffie-Hellman Exchange |
| |
| Authors: | A. Brusilovsky, I. Faynberg, Z. Zeltsan, S. Patel. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5683 |
|
This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called the Password-Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange.
The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy. |
|
| |
| RFC 5684 | Unintended Consequences of NAT Deployments with Overlapping Address Space |
| |
| Authors: | P. Srisuresh, B. Ford. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5684 |
|
This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using NetworkAddress Translator (NAT) devices. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces.Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks(VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. |
|
| |
| RFC 5685 | Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | V. Devarapalli, K. Weniger. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5685 |
|
The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. |
|
| |
| RFC 5686 | RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec |
| |
| Authors: | Y. Hiwasaki, H. Ohmuro. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5686 |
|
This document describes the RTP payload format of a mU-law EMbeddedCoder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. |
|
| |
| RFC 5687 | GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements |
| |
| Authors: | H. Tschofenig, H. Schulzrinne. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5687 |
|
This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) LocationConfiguration Protocol (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from aLocation Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation (LoST) Protocol or to convey location within the Session Initiation Protocol (SIP) to other entities. |
|
| |
| RFC 5688 | A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes |
| |
| Authors: | J. Rosenberg. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5688 |
|
The caller preferences specification for the Session InitiationProtocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities.Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and it provides insufficient granularity as a capability. This specification allows a UA to indicate which application subtypes the agent supports. |
|
| |
| RFC 5689 | Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) |
| |
|
|
This specification extends the Web Distributed Authoring andVersioning (WebDAV) MKCOL (Make Collection) method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. |
|
| |
| RFC 5690 | Adding Acknowledgement Congestion Control to TCP |
| |
| Authors: | S. Floyd, A. Arcia, D. Ros, J. Iyengar. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5690 |
|
This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and theTCP data receiver. The TCP data sender detects lost or ExplicitCongestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's)Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. |
|
| |
| RFC 5691 | RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio |
| |
| Authors: | F. de Bont, S. Doehla, M. Schmidt, R. Sperschneider. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updates: | RFC 3640 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5691 |
|
This memo describes extensions for the RTP payload format defined inRFC 3640 for the transport of MPEG Surround multi-channel audio.Additional Media Type parameters are defined to signal backwards- compatible transmission inside an MPEG-4 Audio elementary stream. In addition, a layered transmission scheme that doesn't use the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. |
|
| |
| RFC 5692 | Transmission of IP over Ethernet over IEEE 802.16 Networks |
| |
| Authors: | H. Jeon, S. Jeong, M. Riegel. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5692 |
|
This document describes the transmission of IPv4 over Ethernet, as well as IPv6 over Ethernet, in an access network deploying the IEEE802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections that IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control(MAC) functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP-specific support functions in the Ethernet overIEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. |
|
| |
| RFC 5693 | Application-Layer Traffic Optimization (ALTO) Problem Statement |
| |
| Authors: | J. Seedorf, E. Burger. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5693 |
|
Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.
This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. |
|
| |
| RFC 5694 | Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability |
| |
| Authors: | G. Camarillo, Ed., IAB. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5694 |
|
In this document, we provide a survey of P2P (Peer-to-Peer) systems.The survey includes a definition and several taxonomies of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural trade-offs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application. |
|
| |
| RFC 5695 | MPLS Forwarding Benchmarking Methodology for IP Flows |
| |
| Authors: | A. Akhter, R. Asati, C. Pignataro. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5695 |
|
This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows. It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF BenchmarkingMethodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. |
|
| |
| RFC 5696 | Baseline Encoding and Transport of Pre-Congestion Information |
| |
| Authors: | T. Moncaster, B. Briscoe, M. Menth. |
| Date: | November 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6660 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5696 |
|
The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging toPCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. |
|
| |
| RFC 5697 | Other Certificates Extension |
| |
| Authors: | S. Farrell. |
| Date: | November 2009 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5697 |
|
Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit. |
|
| |
| RFC 5698 | Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) |
| |
| Authors: | T. Kunz, S. Okunick, U. Pordesch. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5698 |
|
Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time, which may be in the past, the present, or the future. |
|
