| |
| RFC 3700 | Internet Official Protocol Standards |
| |
|
|
This memo contains a snapshot of the state of standardization of protocols used in the Internet as of July 22, 2004. It lists official protocol standards and Best Current Practice RFCs; it is not a complete index to the RFC series. The latest version of this memo is designated STD 1. |
|
| |
| RFC 3701 | 6bone (IPv6 Testing Address Allocation) Phaseout |
| |
|
|
The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This document establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this.
This document obsoletes RFC 2471, "IPv6 Testing Address Allocation",December, 1998. RFC 2471 will become historic. |
|
| |
| RFC 3702 | Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Loughney, G. Camarillo. |
| Date: | February 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3702 |
|
As Session Initiation Protocol (SIP) services are deployed on theInternet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work. |
|
| |
| RFC 3703 | Policy Core Lightweight Directory Access Protocol (LDAP) Schema |
| |
| Authors: | J. Strassner, B. Moore, R. Moats, E. Ellesson. |
| Date: | February 2004 |
| Formats: | txt json html |
| Updated by: | RFC 4104 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3703 |
|
This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that usesLightweight Directory Access Protocol (LDAP) as its access protocol.This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information.These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. |
|
| |
| RFC 3704 | Ingress Filtering for Multihomed Networks |
| |
|
|
BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting theInternet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. |
|
| |
| RFC 3705 | High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals |
| |
| Authors: | B. Ray, R. Abbi. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3705 |
|
This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856. |
|
| |
| RFC 3706 | A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers |
| |
| Authors: | G. Huang, S. Beaulieu, D. Rochefort. |
| Date: | February 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3706 |
|
This document describes the method detecting a dead Internet KeyExchange (IKE) peer that is presently in use by a number of vendors.The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources. |
|
| |
| RFC 3707 | Cross Registry Internet Service Protocol (CRISP) Requirements |
| |
| Authors: | A. Newton. |
| Date: | February 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3707 |
|
Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. |
|
| |
| RFC 3708 | Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions |
| |
| Authors: | E. Blanton, M. Allman. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3708 |
|
TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate SelectiveAcknowledgement (DSACKs) and Duplicate Transmission Sequence Number(TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications. |
|
| |
| RFC 3709 | Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates |
| |
| Authors: | S. Santesson, R. Housley, T. Freeman. |
| Date: | February 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9399 |
| Updated by: | RFC 6170 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3709 |
|
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. |
|
| |
| RFC 3710 | An IESG charter |
| |
|
|
This memo provides a charter for the Internet Engineering SteeringGroup (IESG), a management function of the Internet Engineering TaskForce (IETF). It is meant to document the charter of the IESG as it is presently understood. |
|
| |
| RFC 3711 | The Secure Real-time Transport Protocol (SRTP) |
| |
|
|
This document describes the Secure Real-time Transport Protocol(SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, theReal-time Transport Control Protocol (RTCP). |
|
| |
| RFC 3712 | Lightweight Directory Access Protocol (LDAP): Schema for Printer Services |
| |
| Authors: | P. Fleming, I. McDonald. |
| Date: | February 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7612 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3712 |
|
This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that supportLightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of InternetPrinting Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). |
|
| |
| RFC 3713 | A Description of the Camellia Encryption Algorithm |
| |
| Authors: | M. Matsui, J. Nakajima, S. Moriai. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3713 |
|
This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. |
|
| |
| RFC 3714 | IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet |
| |
| Authors: | S. Floyd, Ed., J. Kempf, Ed.. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3714 |
|
This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet.These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service(QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice overInternet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in theInternet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic. |
|
| |
| RFC 3715 | IPsec-Network Address Translation (NAT) Compatibility Requirements |
| |
| Authors: | B. Aboba, W. Dixon. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3715 |
|
This document describes known incompatibilities between NetworkAddress Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment ofIPsec in one of its principal uses. |
|
| |
| RFC 3716 | IETF in the Large: Administration and Execution |
| |
| Authors: | IAB Advisory Committee. |
| Date: | March 2004 |
| Formats: | txt json html |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 3716 |
|
In the fall of 2003, the IETF Chair and the IAB Chair formed an IABAdvisory Committee (AdvComm), with a mandate to review the existingIETF administrative structure and relationships (RFC Editor, IETFSecretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF.The AdvComm mandate did not include the standards process itself.
This memo documents the AdvComm's findings and proposals. |
|
| |
| RFC 3717 | IP over Optical Networks: A Framework |
| |
| Authors: | B. Rajagopalan, J. Luciani, D. Awduche. |
| Date: | March 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3717 |
|
The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as "IP over optical networks"). |
|
| |
| RFC 3718 | A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access |
| |
| Authors: | R. McGowan. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3718 |
|
This memo describes various internal workings of the UnicodeConsortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding & standardization processes. |
|
| |
| RFC 3719 | Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) |
| |
| Authors: | J. Parker, Ed.. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3719 |
|
This document discusses a number of differences between theIntermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today.These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic. |
|
| |
| RFC 3720 | Internet Small Computer Systems Interface (iSCSI) |
| |
|
|
This document describes a transport protocol for Internet SmallComputer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model.
SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.).
As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI. |
|
| |
| RFC 3721 | Internet Small Computer Systems Interface (iSCSI) Naming and Discovery |
| |
| Authors: | M. Bakke, J. Hafner, J. Hufferd, K. Voruganti, M. Krueger. |
| Date: | April 2004 |
| Formats: | txt html json |
| Updated by: | RFC 7143 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3721 |
|
This document provides examples of the Internet Small ComputerSystems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document.Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. |
|
| |
| RFC 3722 | String Profile for Internet Small Computer Systems Interface (iSCSI) Names |
| |
| Authors: | M. Bakke. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3722 |
|
This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world.
The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network.The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared. |
|
| |
| RFC 3723 | Securing Block Storage Protocols over IP |
| |
| Authors: | B. Aboba, J. Tseng, J. Walker, V. Rangan, F. Travostino. |
| Date: | April 2004 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3723 |
|
This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small ComputerSystem Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (InternetStorage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed. |
|
| |
| RFC 3724 | The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture |
| |
| Authors: | J. Kempf, Ed., R. Austein, Ed., IAB. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3724 |
|
The end-to-end principle is the core architectural guideline of theInternet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. |
|
| |
| RFC 3725 | Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo. |
| Date: | April 2004 |
| Formats: | txt html json |
| Also: | BCP 0085 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3725 |
|
Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. |
|
| |
| RFC 3726 | Requirements for Signaling Protocols |
| |
| Authors: | M. Brunner, Ed.. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3726 |
|
This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined.For example, signaling for label distribution in Multiprotocol LabelSwitching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. |
|
| |
| RFC 3727 | ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules |
| |
| Authors: | S. Legg. |
| Date: | February 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3727 |
|
This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One(ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules. |
|
| |
| RFC 3728 | Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) |
| |
| Authors: | B. Ray, R. Abbi. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3728 |
|
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 Very High SpeedDigital Subscriber Line (VDSL) interfaces. |
|
| |
| RFC 3729 | Application Performance Measurement MIB |
| |
| Authors: | S. Waldbusser. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3729 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for measuring the application performance as experienced by end-users. |
|
| |
| RFC 3730 | Extensible Provisioning Protocol (EPP) |
| |
|
|
This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. |
|
| |
| RFC 3731 | Extensible Provisioning Protocol (EPP) Domain Name Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. |
|
| |
| RFC 3732 | Extensible Provisioning Protocol (EPP) Host Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. |
|
| |
| RFC 3733 | Extensible Provisioning Protocol (EPP) Contact Mapping |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. |
|
| |
| RFC 3734 | Extensible Provisioning Protocol (EPP) Transport Over TCP |
| |
|
|
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server. |
|
| |
| RFC 3735 | Guidelines for Extending the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | S. Hollenbeck. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3735 |
|
The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities. |
|
| |
| RFC 3736 | Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 |
| |
|
|
Stateless Dynamic Host Configuration Protocol service for IPv6(DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP. |
|
| |
| RFC 3737 | IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules |
| |
| Authors: | B. Wijnen, A. Bierman. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3737 |
|
This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring(rmon) root. This memo also documents the currently assigned values. |
|
| |
| RFC 3738 | Wave and Equation Based Rate Control (WEBRC) Building Block |
| |
| Authors: | M. Luby, V. Goyal. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3738 |
|
This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender.Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender. |
|
| |
| RFC 3739 | Internet X.509 Public Key Infrastructure: Qualified Certificates Profile |
| |
| Authors: | S. Santesson, M. Nystrom, T. Polk. |
| Date: | March 2004 |
| Formats: | txt html json |
| Obsoletes: | RFC 3039 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3739 |
|
This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons.
The profile defines specific conventions for certificates that are qualified within a defined legal framework, named QualifiedCertificates. However, the profile does not define any legal requirements for such Qualified Certificates.
The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements. The profile is however not limited to QualifiedCertificates and further profiling may facilitate specific local needs. |
|
| |
| RFC 3740 | The Multicast Group Security Architecture |
| |
| Authors: | T. Hardjono, B. Weis. |
| Date: | March 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3740 |
|
This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast SecurityReference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. |
|
| |
| RFC 3741 | Exclusive XML Canonicalization, Version 1.0 |
| |
| Authors: | J. Boyer, D. Eastlake 3rd, J. Reagle. |
| Date: | March 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3741 |
|
Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the"xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization. |
|
| |
| RFC 3742 | Limited Slow-Start for TCP with Large Congestion Windows |
| |
| Authors: | S. Floyd. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3742 |
|
This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender'sMAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describesLimited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance forTCP connections with large congestion windows. |
|
| |
| RFC 3743 | Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean |
| |
| Authors: | K. Konishi, K. Huang, H. Qian, Y. Ko. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3743 |
|
Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration.
The IETF Standards for Internationalized Domain Names, known as"IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts. |
|
| |
| RFC 3744 | Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol |
| |
| Authors: | G. Clemm, J. Reschke, E. Sedlar, J. Whitehead. |
| Date: | May 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3744 |
|
This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to theWebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such asHyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names. |
|
| |
| RFC 3745 | MIME Type Registrations for JPEG 2000 (ISO/IEC 15444) |
| |
| Authors: | D. Singer, R. Clark, D. Lee. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3745 |
|
This document serves to register and document the standard MIME types associated with the ISO/IEC 15444 standards, commonly known as JPEG2000 (Joint Photographic Experts Group). |
|
| |
| RFC 3746 | Forwarding and Control Element Separation (ForCES) Framework |
| |
| Authors: | L. Yang, R. Dantu, T. Anderson, R. Gopal. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3746 |
|
This document defines the architectural framework for the ForCES(Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions. |
|
| |
| RFC 3747 | The Differentiated Services Configuration MIB |
| |
| Authors: | H. Hazewinkel, Ed., D. Partain, Ed.. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3747 |
|
This memo describes a MIB module that provides a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB. |
|
| |
| RFC 3748 | Extensible Authentication Protocol (EAP) |
| |
|
|
This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such asPoint-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees.Fragmentation is not supported within EAP itself; however, individualEAP methods may support this.
This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. |
|
| |
| RFC 3749 | Transport Layer Security Protocol Compression Methods |
| |
|
|
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS RecordProtocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use withTLS, and it describes a method for the specification of additionalTLS compression methods. |
|
| |
| RFC 3750 | Unmanaged Networks IPv6 Transition Scenarios |
| |
| Authors: | C. Huitema, R. Austein, S. Satapati, R. van der Pol. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3750 |
|
This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged network", which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. |
|
| |
| RFC 3751 | Omniscience Protocol Requirements |
| |
| Authors: | S. Bradner. |
| Date: | 1 April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3751 |
|
There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, theOmniscience Protocol, that could be used to enable such efforts. |
|
| |
| RFC 3752 | Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios |
| |
| Authors: | A. Barbir, E. Burger, R. Chen, S. McHenry, H. Orman, R. Penno. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3752 |
|
This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. |
|
| |
| RFC 3753 | Mobility Related Terminology |
| |
| Authors: | J. Manner, Ed., M. Kojo, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3753 |
|
There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in theSeamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology. |
|
| |
| RFC 3754 | IP Multicast in Differentiated Services (DS) Networks |
| |
| Authors: | R. Bless, K. Wehrle. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3754 |
|
This document discusses the problems of IP Multicast use inDifferentiated Services (DS) networks, expanding on the discussion inRFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results. |
|
| |
| RFC 3755 | Legacy Resolver Compatibility for Delegation Signer (DS) |
| |
|
|
As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed.Many deployed nameservers understand variants of these semantics.Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. |
|
| |
| RFC 3756 | IPv6 Neighbor Discovery (ND) Trust Models and Threats |
| |
| Authors: | P. Nikander, Ed., J. Kempf, E. Nordmark. |
| Date: | May 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3756 |
|
The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsecAuthentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. |
|
| |
| RFC 3757 | Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag |
| |
|
|
With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the DomainName System KEY (DNSKEY) resource record set. A flag bit in theDNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC2535 and RFC 3755. |
|
| |
| RFC 3758 | Stream Control Transmission Protocol (SCTP) Partial Reliability Extension |
| |
| Authors: | R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad. |
| Date: | May 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3758 |
|
This memo describes an extension to the Stream Control TransmissionProtocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism. |
|
| |
| RFC 3759 | RObust Header Compression (ROHC): Terminology and Channel Mapping Examples |
| |
|
|
This document aims to clarify terms and concepts presented in RFC3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues. |
|
| |
| RFC 3760 | Securely Available Credentials (SACRED) - Credential Server Framework |
| |
| Authors: | D. Gustafson, M. Just, M. Nystrom. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3760 |
|
As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework. |
|
| |
| RFC 3761 | The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) |
| |
|
|
This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the DynamicDelegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. |
|
| |
| RFC 3762 | Telephone Number Mapping (ENUM) Service Registration for H.323 |
| |
|
|
The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone NumberMapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761. |
|
| |
| RFC 3763 | One-way Active Measurement Protocol (OWAMP) Requirements |
| |
| Authors: | S. Shalunov, B. Teitelbaum. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3763 |
|
With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol(OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. |
|
| |
| RFC 3764 | enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record |
| |
|
|
This document registers an Electronic Number (ENUM) service for theSession Initiation Protocol (SIP), pursuant to the guidelines in RFC3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM. |
|
| |
| RFC 3765 | NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control |
| |
| Authors: | G. Huston. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3765 |
|
This document describes the use of a scope control Border GatewayProtocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. |
|
| |
| RFC 3766 | Determining Strengths For Public Keys Used For Exchanging Symmetric Keys |
| |
|
|
Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage.
While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of a symmetric key strength requirement. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. |
|
| |
| RFC 3767 | Securely Available Credentials Protocol |
| |
|
|
This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration.The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support forTLS and/or DIGEST-MD5 (through BEEP). |
|
| |
| RFC 3768 | Virtual Router Redundancy Protocol (VRRP) |
| |
|
|
This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on aLAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. |
|
| |
| RFC 3769 | Requirements for IPv6 Prefix Delegation |
| |
| Authors: | S. Miyakawa, R. Droms. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3769 |
|
This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site"). |
|
| |
| RFC 3770 | Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) |
| |
|
|
This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). |
|
| |
| RFC 3771 | The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message |
| |
|
|
This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). TheIntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAPExtendedRequest and ExtendedResponse to define new single- request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information. |
|
| |
| RFC 3772 | Point-to-Point Protocol (PPP) Vendor Protocol |
| |
| Authors: | J. Carlson, R. Winslow. |
| Date: | May 2004 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3772 |
|
The Point-to-Point Protocol (PPP) defines a Link Control Protocol(LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor- specific Network, Authentication, and Control Protocols. |
|
| |
| RFC 3773 | High-Level Requirements for Internet Voice Mail |
| |
| Authors: | E. Candell. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3773 |
|
This document describes the high-level requirements for InternetVoice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for InternetMail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment.This document does not include goals that were met fully by VPIM version 2. |
|
| |
| RFC 3774 | IETF Problem Statement |
| |
| Authors: | E. Davies, Ed.. |
| Date: | May 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3774 |
|
This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community.
The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections. |
|
| |
| RFC 3775 | Mobility Support in IPv6 |
| |
| Authors: | D. Johnson, C. Perkins, J. Arkko. |
| Date: | June 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6275 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3775 |
|
This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation,Mobile IPv6 defines a new IPv6 protocol and a new destination option.All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. |
|
| |
| RFC 3776 | Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents |
| |
| Authors: | J. Arkko, V. Devarapalli, F. Dupont. |
| Date: | June 2004 |
| Formats: | txt html json |
| Updated by: | RFC 4877 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3776 |
|
Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order. |
|
| |
| RFC 3777 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. This document is a self- consistent, organized compilation of the process as it was known at the time of publication. |
|
| |
| RFC 3778 | The application/pdf Media Type |
| |
| Authors: | E. Taft, J. Pravetz, S. Zilles, L. Masinter. |
| Date: | May 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8118 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3778 |
|
PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of thePDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. |
|
| |
| RFC 3779 | X.509 Extensions for IP Addresses and AS Identifiers |
| |
| Authors: | C. Lynn, S. Kent, K. Seo. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3779 |
|
This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. |
|
| |
| RFC 3780 | SMIng - Next Generation Structure of Management Information |
| |
| Authors: | F. Strauss, J. Schoenwaelder. |
| Date: | May 2004 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3780 |
|
This memo defines the base SMIng (Structure of ManagementInformation, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP. |
|
| |
| RFC 3781 | Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP) |
| |
| Authors: | F. Strauss, J. Schoenwaelder. |
| Date: | May 2004 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3781 |
|
SMIng (Structure of Management Information, Next Generation)(RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework. |
|
| |
| RFC 3782 | The NewReno Modification to TCP's Fast Recovery Algorithm |
| |
|
|
The purpose of this document is to advance NewReno TCP's FastRetransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status.
The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewRenoTCP. |
|
| |
| RFC 3783 | Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI |
| |
| Authors: | M. Chadalapaka, R. Elliott. |
| Date: | May 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3783 |
|
Internet Small Computer Systems Interface (iSCSI) is a Small ComputerSystems Interface (SCSI) transport protocol designed to run on top ofTCP. The iSCSI session abstraction is equivalent to the classic SCSI"I_T nexus", which represents the logical relationship between anInitiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. |
|
| |
| RFC 3784 | Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) |
| |
|
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Traffic Engineering(TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in LinkState Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. |
|
| |
| RFC 3785 | Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric |
| |
| Authors: | F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx, T. Telkamp. |
| Date: | May 2004 |
| Formats: | txt json html |
| Also: | BCP 0087 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 3785 |
|
This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint BasedRouting of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to performConstraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. |
|
| |
| RFC 3786 | Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit |
| |
| Authors: | A. Hermelin, S. Previdi, M. Shand. |
| Date: | May 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5311 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3786 |
|
This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. |
|
| |
| RFC 3787 | Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) |
| |
| Authors: | J. Parker, Ed.. |
| Date: | May 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3787 |
|
This document discusses a number of differences between theIntermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice. |
|
| |
| RFC 3788 | Security Considerations for Signaling Transport (SIGTRAN) Protocols |
| |
| Authors: | J. Loughney, M. Tuexen, Ed., J. Pastor-Balbas. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3788 |
|
This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional. |
|
| |
| RFC 3789 | Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents |
| |
| Authors: | P. Nesser, II, A. Bergstrom, Ed.. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3789 |
|
This document is a general overview and introduction to the v6opsIETF workgroup project of documenting all usage of IPv4 addresses inIETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results. |
|
| |
| RFC 3790 | Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents |
| |
| Authors: | C. Mickles, Ed., P. Nesser, II. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3790 |
|
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3791 | Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents |
| |
| Authors: | C. Olvera, P. Nesser, II. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3791 |
|
This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an allIPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies.It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3792 | Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents |
| |
| Authors: | P. Nesser, II, A. Bergstrom, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3792 |
|
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3793 | Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents |
| |
| Authors: | P. Nesser, II, A. Bergstrom, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3793 |
|
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3794 | Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents |
| |
| Authors: | P. Nesser, II, A. Bergstrom, Ed.. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3794 |
|
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an allIPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies.It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3795 | Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents |
| |
| Authors: | R. Sofia, P. Nesser, II. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3795 |
|
This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6.
To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, andProposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF ApplicationArea documented Standards may experience. |
|
| |
| RFC 3796 | Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents |
| |
| Authors: | P. Nesser, II, A. Bergstrom, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3796 |
|
This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4Internet to an all IPv6 Internet, many interim steps will be taken.One of these steps is the evolution of current protocols that haveIPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 andIPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3797 | Publicly Verifiable Nominations Committee (NomCom) Random Selection |
| |
|
|
This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. |
|
| |
| RFC 3798 | Message Disposition Notification |
| |
|
|
This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient.This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message DispositionNotifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary"LAN-based" systems, and often referred to as "read receipts,""acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. |
|
