| |
| RFC 4801 | Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management |
| |
| Authors: | T. Nadeau, Ed., A. Farrel, Ed.. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4801 |
|
This document defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly usedGeneralized Multiprotocol Label Switching (GMPLS) management information. The intent is that these textual conventions will be imported and used in GMPLS-related MIB modules that would otherwise define their own representations. |
|
| |
| RFC 4802 | Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base |
| |
| Authors: | T. Nadeau, Ed., A. Farrel, Ed.. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4802 |
|
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 GeneralizedMultiprotocol Label Switching (GMPLS)-based traffic engineering. |
|
| |
| RFC 4803 | Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base |
| |
| Authors: | T. Nadeau, Ed., A. Farrel, Ed.. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4803 |
|
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 to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) LabelSwitching Router (LSR). |
|
| |
| RFC 4804 | Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels |
| |
| Authors: | F. Le Faucheur, Ed.. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4804 |
|
RFC 3175 specifies aggregation of Resource ReSerVation Protocol(RSVP) end-to-end reservations over aggregate RSVP reservations.This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-awareMPLS Traffic Engineering (DS-TE) tunnels. This approach is based onRFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. |
|
| |
| RFC 4805 | Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types |
| |
|
|
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 objects used for managing DS1, J1, E1,DS2, and E2 interfaces. This document is a companion to the documents that define managed objects for the DS0, DS3/E3, andSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Interface Types.
This document obsoletes RFC 3895. |
|
| |
| RFC 4806 | Online Certificate Status Protocol (OCSP) Extensions to IKEv2 |
| |
| Authors: | M. Myers, H. Tschofenig. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4806 |
|
While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-bandCertificate Revocation Lists (CRL) is problematic due to unboundedCRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSPContent" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.
When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies whenOCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. |
|
| |
| RFC 4807 | IPsec Security Policy Database Configuration MIB |
| |
| Authors: | M. Baer, R. Charlet, W. Hardaker, R. Story, C. Wang. |
| Date: | March 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4807 |
|
This document defines a Structure of Management Information Version 2(SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol.The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions. |
|
| |
| RFC 4808 | Key Change Strategies for TCP-MD5 |
| |
| Authors: | S. Bellovin. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4808 |
|
The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit(mostly) unsynchronized key changes. |
|
| |
| RFC 4809 | Requirements for an IPsec Certificate Management Profile |
| |
| Authors: | C. Bonatti, Ed., S. Turner, Ed., G. Lebovitz, Ed.. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4809 |
|
This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) VirtualPrivate Network (VPN) Systems using Internet Key Exchange (IKE)(versions 1 and 2) and Public Key Infrastructure (PKI) Systems.These requirements are designed to meet the needs of enterprise-scaleIPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements. |
|
| |
| RFC 4810 | Long-Term Archive Service Requirements |
| |
| Authors: | C. Wallace, U. Pordesch, R. Brandner. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4810 |
|
There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. |
|
| |
| RFC 4811 | OSPF Out-of-Band Link State Database (LSDB) Resynchronization |
| |
| Authors: | L. Nguyen, A. Roy, A. Zinin. |
| Date: | March 2007 |
| Formats: | txt json html |
| Updated by: | RFC 9454 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4811 |
|
OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize theirLSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.
This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. |
|
| |
| RFC 4812 | OSPF Restart Signaling |
| |
| Authors: | L. Nguyen, A. Roy, A. Zinin. |
| Date: | March 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4812 |
|
OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via theHello subprotocol. Hello OSPF packets are also used to ensure two- way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends aHello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions.
This memo describes a vendor-specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before GracefulOSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. |
|
| |
| RFC 4813 | OSPF Link-Local Signaling |
| |
| Authors: | B. Friedman, L. Nguyen, A. Roy, D. Yeung, A. Zinin. |
| Date: | March 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5613 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4813 |
|
OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. |
|
| |
| RFC 4814 | Hash and Stuffing: Overlooked Factors in Network Device Benchmarking |
| |
| Authors: | D. Newman, T. Player. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4814 |
|
Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results.First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. |
|
| |
| RFC 4815 | RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 |
| |
|
|
RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol),RTP (Real-Time Transport Protocol), and ESP (Encapsulating SecurityPayload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) andRFC 4109 (ROHC UDP-Lite profiles) are also provided. |
|
| |
| RFC 4816 | Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service |
| |
| Authors: | A. Malis, L. Martini, J. Brayley, T. Walsh. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4816 |
|
The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for Pseudowire EmulationEdge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell encapsulation. |
|
| |
| RFC 4817 | Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 |
| |
| Authors: | M. Townsley, C. Pignataro, S. Wainner, T. Seely, J. Young. |
| Date: | March 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4817 |
|
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize anL2TPv3 encapsulation over an IP network instead. |
|
| |
| RFC 4818 | RADIUS Delegated-IPv6-Prefix Attribute |
| |
| Authors: | J. Salowey, R. Droms. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4818 |
|
This document defines a RADIUS (Remote Authentication Dial In UserService) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. |
|
| |
| RFC 4819 | Secure Shell Public Key Subsystem |
| |
| Authors: | J. Galbraith, J. Van Dyke, J. Bright. |
| Date: | March 2007 |
| Formats: | txt json html |
| Updated by: | RFC 9519 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4819 |
|
Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution.No common key management solution exists in current implementations.This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration.
The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user.
A public key may also be associated with various restrictions, including a mandatory command or subsystem. |
|
| |
| RFC 4820 | Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | M. Tuexen, R. Stewart, P. Lei. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4820 |
|
This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. The padding chunk is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size. The padding parameter is used to pad an SCTPINIT chunk to an arbitrary size. |
|
| |
| RFC 4821 | Packetization Layer Path MTU Discovery |
| |
| Authors: | M. Mathis, J. Heffner. |
| Date: | March 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8899 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4821 |
|
This document describes a robust method for Path MTU Discovery(PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specifyICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. |
|
| |
| RFC 4822 | RIPv2 Cryptographic Authentication |
| |
|
|
This note describes a revision to the RIPv2 CryptographicAuthentication mechanism originally specified in RFC 2082. This document obsoletes RFC 2082 and updates RFC 2453. This document adds details of how the SHA family of hash algorithms can be used withRIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section. |
|
| |
| RFC 4823 | FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet |
| |
|
|
This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol(FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 orUN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. |
|
| |
| RFC 4824 | The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS) |
| |
| Authors: | J. Hofmueller, Ed., A. Bachmann, Ed., IO. zmoelnig, Ed.. |
| Date: | 1 April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4824 |
|
This document specifies a method for encapsulating and transmittingIPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). |
|
| |
| RFC 4825 | The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) |
| |
| Authors: | J. Rosenberg. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4825 |
|
This specification defines the Extensible Markup Language (XML)Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed byHTTP. |
|
| |
| RFC 4826 | Extensible Markup Language (XML) Formats for Representing Resource Lists |
| |
| Authors: | J. Rosenberg. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4826 |
|
In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers(URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends aSession Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents.One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XMLConfiguration Access Protocol (XCAP). |
|
| |
| RFC 4827 | An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents |
| |
| Authors: | M. Isomaki, E. Leppanen. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4827 |
|
This document describes a usage of the Extensible Markup Language(XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol(SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity. |
|
| |
| RFC 4828 | TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant |
| |
| Authors: | S. Floyd, E. Kohler. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4828 |
|
This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.
TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment(RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.
Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small- packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth. |
|
| |
| RFC 4829 | Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering |
| |
| Authors: | J. de Oliveira, Ed., JP. Vasseur, Ed., L. Chen, C. Scoglio. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4829 |
|
When the establishment of a higher priority (Traffic EngineeringLabel Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select whichTE LSPs will be preempted. The preempted LSPs are then rerouted by their respective Head-end Label Switch Router (LSR). This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TELSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included. |
|
| |
| RFC 4830 | Problem Statement for Network-Based Localized Mobility Management (NETLMM) |
| |
| Authors: | J. Kempf, Ed.. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4830 |
|
Localized mobility management is a well-understood concept in theIETF, with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management. |
|
| |
| RFC 4831 | Goals for Network-Based Localized Mobility Management (NETLMM) |
| |
| Authors: | J. Kempf, Ed.. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4831 |
|
In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed. |
|
| |
| RFC 4832 | Security Threats to Network-Based Localized Mobility Management (NETLMM) |
| |
| Authors: | C. Vogt, J. Kempf. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4832 |
|
This document discusses security threats to network-based localized mobility management. Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node. Threats to the former interface impact the localized mobility management protocol itself. |
|
| |
| RFC 4833 | Timezone Options for DHCP |
| |
|
|
Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifiesDHCP options for each of those methods. The DHCPv4 time offset option is deprecated. |
|
| |
| RFC 4834 | Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) |
| |
| Authors: | T. Morin, Ed.. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4834 |
|
This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3(L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines. |
|
| |
| RFC 4835 | Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
|
|
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The EncapsulatingSecurity Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec SecurityAssociation (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. |
|
| |
| RFC 4836 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
|
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3Medium Attachment Units (MAUs). This document obsoletes RFC 3636.It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate InternetAssigned Number Authority (IANA) maintained MIB module. In addition, management information is added to enable support for Ethernet in theFirst Mile (EFM) and 10GBASE-CX4 MAUs. |
|
| |
| RFC 4837 | Managed Objects of Ethernet Passive Optical Networks (EPON) |
| |
| Authors: | L. Khermosh. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4837 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP basedInternets. In particular, it defines objects for managing interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. |
|
| |
| RFC 4838 | Delay-Tolerant Networking Architecture |
| |
| Authors: | V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, H. Weiss. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4838 |
|
This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. |
|
| |
| RFC 4839 | Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF) |
| |
| Authors: | G. Conboy, J. Rivlin, J. Ferraiolo. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4839 |
|
This document serves to register a media type for the Open eBookPublication Structure (OEBPS) Package Files. |
|
| |
| RFC 4840 | Multiple Encapsulation Methods Considered Harmful |
| |
| Authors: | B. Aboba, Ed., E. Davies, D. Thaler. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4840 |
|
This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods. |
|
| |
| RFC 4841 | RFC 4181 Update to Recognize the IETF Trust |
| |
|
|
This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. |
|
| |
| RFC 4842 | Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) |
| |
| Authors: | A. Malis, P. Pate, R. Cohen, Ed., D. Zelig. |
| Date: | April 2007 |
| Formats: | txt json html |
| Obsoletes: | RFC 5143 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4842 |
|
This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy(SONET/SDH) circuits and services over MPLS. |
|
| |
| RFC 4843 | An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) |
| |
| Authors: | P. Nikander, J. Laganier, F. Dupont. |
| Date: | April 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7343 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4843 |
|
This document introduces Overlay Routable Cryptographic HashIdentifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application ProgrammingInterfaces (API) and not as identifiers for network location at theIP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level.Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with currentIPv6 addresses.
This document requests IANA to allocate a temporary prefix out of theIPv6 addressing space for Overlay Routable Cryptographic HashIdentifiers. By default, the prefix will be returned to IANA in2014, with continued use requiring IETF consensus. |
|
| |
| RFC 4844 | The RFC Series and RFC Editor |
| |
|
|
This document describes the framework for an RFC Series and an RFCEditor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFCSeries to continue to fulfill its mandate. |
|
| |
| RFC 4845 | Process for Publication of IAB RFCs |
| |
| Authors: | L. Daigle, Ed., Internet Architecture Board. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4845 |
|
From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC Series. |
|
| |
| RFC 4846 | Independent Submissions to the RFC Editor |
| |
| Authors: | J. Klensin, Ed., D. Thaler, Ed.. |
| Date: | July 2007 |
| Formats: | txt json html |
| Updated by: | RFC 5744 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4846 |
|
There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms.These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. |
|
| |
| RFC 4847 | Framework and Requirements for Layer 1 Virtual Private Networks |
| |
| Authors: | T. Takeda, Ed.. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4847 |
|
This document provides a framework and service level requirements forLayer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.
The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. |
|
| |
| RFC 4848 | Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) |
| |
| Authors: | L. Daigle. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4848 |
|
The purpose of this document is to define a new, straightforwardDynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbedU-NAPTR, this is effectively an extension of the StraightforwardNAPTR (S-NAPTR) DDDS Application. |
|
| |
| RFC 4849 | RADIUS Filter Rule Attribute |
| |
| Authors: | P. Congdon, M. Sanchez, B. Aboba. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4849 |
|
While RFC 2865 defines the Filter-Id attribute, it requires that theNetwork Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service(RADIUS). This attribute is based on the Diameter NAS-Filter-RuleAttribute Value Pair (AVP) described in RFC 4005, and theIPFilterRule syntax defined in RFC 3588. |
|
| |
| RFC 4850 | Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture |
| |
|
|
The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. |
|
| |
| RFC 4851 | The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) |
| |
|
|
This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the TransportLayer Security (TLS) to establish a mutually authenticated tunnel.Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. |
|
| |
| RFC 4852 | IPv6 Enterprise Network Analysis - IP Layer 3 Focus |
| |
| Authors: | J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4852 |
|
This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity.The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network. |
|
| |
| RFC 4853 | Cryptographic Message Syntax (CMS) Multiple Signer Clarification |
| |
|
|
This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present. |
|
| |
| RFC 4854 | A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | P. Saint-Andre. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4854 |
|
This document describes a Uniform Resource Name (URN) namespace for uniquely identifying Extensible Markup Language (XML) formats and protocols that provide extensions to the Extensible Messaging andPresence Protocol (XMPP) and are defined in specifications published by the XMPP Standards Foundation (XSF). |
|
| |
| RFC 4855 | Media Type Registration of RTP Payload Formats |
| |
|
|
This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. |
|
| |
| RFC 4856 | Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences |
| |
|
|
This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences.Some of these may also be used for transfer modes other than RTP. |
|
| |
| RFC 4857 | Mobile IPv4 Regional Registration |
| |
| Authors: | E. Fogelstroem, A. Jonsson, C. Perkins. |
| Date: | June 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4857 |
|
Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. |
|
| |
| RFC 4858 | Document Shepherding from Working Group Last Call to Publication |
| |
| Authors: | H. Levkowetz, D. Meyer, L. Eggert, A. Mankin. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4858 |
|
This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the AreaDirector responsible for the working group has traditionally filled the shepherding role. |
|
| |
| RFC 4859 | Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object |
| |
| Authors: | A. Farrel. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4859 |
|
This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineering(RSVP-TE) signaling messages used in Multiprotocol Label Switching(MPLS) and Generalized MPLS (GMPLS) signaling. |
|
| |
| RFC 4860 | Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations |
| |
| Authors: | F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. Davenport. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4860 |
|
RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end- to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a givenPHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. |
|
| |
| RFC 4861 | Neighbor Discovery for IP version 6 (IPv6) |
| |
| Authors: | T. Narten, E. Nordmark, W. Simpson, H. Soliman. |
| Date: | September 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 2461 |
| Updated by: | RFC 5942, RFC 6980, RFC 7048, RFC 7527, RFC 7559, RFC 8028, RFC 8319, RFC 8425, RFC 9131 |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 4861 |
|
This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. |
|
| |
| RFC 4862 | IPv6 Stateless Address Autoconfiguration |
| |
|
|
This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the DuplicateAddress Detection procedure to verify the uniqueness of the addresses on a link. |
|
| |
| RFC 4863 | Wildcard Pseudowire Type |
| |
| Authors: | L. Martini, G. Swallow. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4863 |
|
Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form ofLDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these twoLSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a Wildcard PW Type to satisfy this need. |
|
| |
| RFC 4864 | Local Network Protection for IPv6 |
| |
| Authors: | G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4864 |
|
Although there are many perceived benefits to Network AddressTranslation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation. |
|
| |
| RFC 4865 | SMTP Submission Service Extension for Future Message Release |
| |
|
|
This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. |
|
| |
| RFC 4866 | Enhanced Route Optimization for Mobile IPv6 |
| |
| Authors: | J. Arkko, C. Vogt, W. Haddad. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4866 |
|
This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. |
|
| |
| RFC 4867 | RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs |
| |
| Authors: | J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. |
| Date: | April 2007 |
| Formats: | txt json html |
| Obsoletes: | RFC 3267 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4867 |
|
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. |
|
| |
| RFC 4868 | Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec |
| |
| Authors: | S. Kelly, S. Frankel. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4868 |
|
This specification describes the use of Hashed Message AuthenticationMode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP),Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128,HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, andPRF-HMAC-SHA-512. |
|
| |
| RFC 4869 | Suite B Cryptographic Suites for IPsec |
| |
|
|
This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with theUnited States National Security Agency's Suite B specifications. |
|
| |
| RFC 4870 | Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) |
| |
|
|
"DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email.
This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today.
Proof and protection of email identity may assist in the global control of "spam" and "phishing". |
|
| |
| RFC 4871 | DomainKeys Identified Mail (DKIM) Signatures |
| |
| Authors: | E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas. |
| Date: | May 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 4870 |
| Obsoleted by: | RFC 6376 |
| Updated by: | RFC 5672 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4871 |
|
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or MailUser Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". |
|
| |
| RFC 4872 | RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery |
| |
|
|
This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) ResourceReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description ofGMPLS recovery can be found in a companion document, RFC 4426. |
|
| |
| RFC 4873 | GMPLS Segment Recovery |
| |
|
|
This document describes protocol specific procedures for GMPLS(Generalized Multi-Protocol Label Switching) RSVP-TE (ResourceReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration.These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).Implications and interactions with fast reroute are also addressed.This document also updates the handling of NOTIFY_REQUEST objects. |
|
| |
| RFC 4874 | Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) |
| |
|
|
This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering(RSVP-TE).
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSPTunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "GeneralizedMulti-Protocol Label Switching (GMPLS) Signaling Resource ReserVationProtocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.
In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared RiskLink Groups (SRLGs) can be excluded is also specified in this document. |
|
| |
| RFC 4875 | Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) |
| |
| Authors: | R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. |
| Date: | May 2007 |
| Formats: | txt html json |
| Updated by: | RFC 6510 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4875 |
|
This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered(TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.
There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TELSP is outside the scope of this document. |
|
| |
| RFC 4876 | A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents |
| |
| Authors: | B. Neal-Joslin, Ed., L. Howard, M. Ansari. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4876 |
|
This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an object class are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support.In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. |
|
| |
| RFC 4877 | Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture |
| |
| Authors: | V. Devarapalli, F. Dupont. |
| Date: | April 2007 |
| Formats: | txt json html |
| Updates: | RFC 3776 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4877 |
|
This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. |
|
| |
| RFC 4878 | Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces |
| |
| Authors: | M. Squire. |
| Date: | June 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4878 |
|
This document defines objects for managing Operations,Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards. The Ethernet OAM functionality is complementary to theSimple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those linkOAM functions and for providing results and status of the OAM functions to management entities. |
|
| |
| RFC 4879 | Clarification of the Third Party Disclosure Procedure in RFC 3979 |
| |
|
|
This document clarifies and updates a single sentence in RFC 3979.Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF ExecutiveDirector notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. |
|
| |
| RFC 4880 | OpenPGP Message Format |
| |
|
|
This document is maintained in order to publish all necessary information needed to develop interoperable applications based on theOpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions.It does, however, discuss implementation issues necessary to avoid security flaws.
OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used inOpenPGP. |
|
| |
| RFC 4881 | Low-Latency Handoffs in Mobile IPv4 |
| |
| Authors: | K. El Malki, Ed.. |
| Date: | June 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4881 |
|
Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real- time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. |
|
| |
| RFC 4882 | IP Address Location Privacy and Mobile IPv6: Problem Statement |
| |
| Authors: | R. Koodli. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4882 |
|
In this document, we discuss location privacy as applicable to MobileIPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent. |
|
| |
| RFC 4883 | Benchmarking Terminology for Resource Reservation Capable Routers |
| |
| Authors: | G. Feher, K. Nemeth, A. Korn, I. Cselenyi. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4883 |
|
The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling ofIntegrated Services (IntServ) IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements. |
|
| |
| RFC 4884 | Extended ICMP to Support Multi-Part Messages |
| |
|
|
This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.
Multi-part messages are supported by an ICMP extension structure.The extension structure is situated at the end of the ICMP message.It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.
This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an"original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length.Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the"original datagram" field.
The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.
This memo updates RFC 792 and RFC 4443. |
|
| |
| RFC 4885 | Network Mobility Support Terminology |
| |
| Authors: | T. Ernst, H-Y. Lach. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4885 |
|
This document defines a terminology for discussing network mobility(NEMO) issues and solution requirements. |
|
| |
| RFC 4886 | Network Mobility Support Goals and Requirements |
| |
| Authors: | T. Ernst. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4886 |
|
Network mobility arises when a router connecting a network to theInternet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. |
|
| |
| RFC 4887 | Network Mobility Home Network Models |
| |
| Authors: | P. Thubert, R. Wakikawa, V. Devarapalli. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4887 |
|
This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists. |
|
| |
| RFC 4888 | Network Mobility Route Optimization Problem Statement |
| |
| Authors: | C. Ng, P. Thubert, M. Watari, F. Zhao. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4888 |
|
With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and HomeAgent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of MobileNetworks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind RouteOptimization (RO) for NEMO. |
|
| |
| RFC 4889 | Network Mobility Route Optimization Solution Space Analysis |
| |
| Authors: | C. Ng, F. Zhao, M. Watari, P. Thubert. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4889 |
|
With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through theMobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO RouteOptimization. |
|
| |
| RFC 4890 | Recommendations for Filtering ICMPv6 Messages in Firewalls |
| |
| Authors: | E. Davies, J. Mohacsi. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4890 |
|
In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.
This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks. |
|
| |
| RFC 4891 | Using IPsec to Secure IPv6-in-IPv4 Tunnels |
| |
| Authors: | R. Graveman, M. Parthasarathy, P. Savola, H. Tschofenig. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4891 |
|
This document gives guidance on securing manually configured IPv6-in-IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework. |
|
| |
| RFC 4892 | Requirements for a Mechanism Identifying a Name Server Instance |
| |
| Authors: | S. Woolf, D. Conrad. |
| Date: | June 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4892 |
|
With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a singleIP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism. |
|
| |
| RFC 4893 | BGP Support for Four-octet AS Number Space |
| |
|
|
Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry theAutonomous System number as a four-octet entity. |
|
| |
| RFC 4894 | Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec |
| |
| Authors: | P. Hoffman. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4894 |
|
This document describes how the IKEv1 (Internet Key Exchange version1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms. |
|
| |
| RFC 4895 | Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | M. Tuexen, R. Stewart, P. Lei, E. Rescorla. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4895 |
|
This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. |
|
| |
| RFC 4896 | Signaling Compression (SigComp) Corrections and Clarifications |
| |
|
|
This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems.SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP).This document updates the following RFCs: RFC 3320, RFC 3321, and RFC3485. |
|
| |
| RFC 4897 | Handling Normative References to Standards-Track Documents |
| |
|
|
The Internet Engineering Task Force (IETF) and Request for Comments(RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. The IETF agreed on a way to bypass this rule with RFC 3967. This document describes a simpler procedure for downward references to Standards-Track and Best CurrentPractice (BCP) documents, namely "note and move on". The procedure in RFC 3967 still applies for downward references to other classes of documents. In both cases, annotations should be added to suchReferences. |
|
| |
| RFC 4898 | TCP Extended Statistics MIB |
| |
| Authors: | M. Mathis, J. Heffner, R. Raghunarayan. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4898 |
|
This document describes extended performance statistics for TCP.They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself.If the bottleneck is in the network, TCP can provide specific information about its nature. |
|
