| |
| RFC 4001 | Textual Conventions for Internet Network Addresses |
| |
| Authors: | M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoletes: | RFC 3291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4001 |
|
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. |
|
| |
| RFC 4002 | IANA Registration for Enumservice 'web' and 'ft' |
| |
| Authors: | R. Brandner, L. Conroy, R. Stastny. |
| Date: | February 2005 |
| Formats: | txt json html |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4002 |
|
This document registers the Enumservices 'web' and 'ft' by using theURI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761). |
|
| |
| RFC 4003 | GMPLS Signaling Procedure for Egress Control |
| |
|
|
This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a LabelSwitched Path (LSP). This control is also known as "Egress Control".Support for Egress Control is implicit in Generalized Multi-ProtocolLabel Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures. |
|
| |
| RFC 4004 | Diameter Mobile IPv4 Application |
| |
| Authors: | P. Calhoun, T. Johansson, C. Perkins, T. Hiller, Ed., P. McCann. |
| Date: | August 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4004 |
|
This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers. |
|
| |
| RFC 4005 | Diameter Network Access Server Application |
| |
| Authors: | P. Calhoun, G. Zorn, D. Spence, D. Mitton. |
| Date: | August 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7155 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4005 |
|
This document describes the Diameter protocol application used forAuthentication, Authorization, and Accounting (AAA) services in theNetwork Access Server (NAS) environment. When combined with theDiameter Base protocol, Transport Profile, and ExtensibleAuthentication Protocol specifications, this application specification satisfies typical network access services requirements.
Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS andDiameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations.
The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol. |
|
| |
| RFC 4006 | Diameter Credit-Control Application |
| |
| Authors: | H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney. |
| Date: | August 2005 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8506 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4006 |
|
This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. |
|
| |
| RFC 4007 | IPv6 Scoped Address Architecture |
| |
| Authors: | S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill. |
| Date: | March 2005 |
| Formats: | txt json html |
| Updated by: | RFC 7346 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4007 |
|
This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. |
|
| |
| RFC 4008 | Definitions of Managed Objects for Network Address Translators (NAT) |
| |
| Authors: | R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, C. Wang. |
| Date: | March 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7658 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4008 |
|
This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function.This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. |
|
| |
| RFC 4009 | The SEED Encryption Algorithm |
| |
| Authors: | J. Park, S. Lee, J. Kim, J. Lee. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4269 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4009 |
|
This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). |
|
| |
| RFC 4010 | Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS) |
| |
| Authors: | J. Park, S. Lee, J. Kim, J. Lee. |
| Date: | February 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4010 |
|
This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).
SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs).One OID class defines the content encryption algorithms and the other defines the key encryption algorithms. |
|
| |
| RFC 4011 | Policy Based Management MIB |
| |
| Authors: | S. Waldbusser, J. Saperia, T. Hongal. |
| Date: | March 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4011 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, this MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol(SNMP) infrastructures, a scripting language, and a script execution environment. |
|
| |
| RFC 4012 | Routing Policy Specification Language next generation (RPSLng) |
| |
|
|
This memo introduces a new set of simple extensions to the RoutingPolicy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. |
|
| |
| RFC 4013 | SASLprep: Stringprep Profile for User Names and Passwords |
| |
|
|
This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the"SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used bySimple Authentication and Security Layer (SASL) mechanisms (such asPLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords. |
|
| |
| RFC 4014 | Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option |
| |
| Authors: | R. Droms, J. Schnizlein. |
| Date: | February 2005 |
| Formats: | txt html json |
| Updated by: | RFC 9445 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4014 |
|
The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. |
|
| |
| RFC 4015 | The Eifel Response Algorithm for TCP |
| |
| Authors: | R. Ludwig, A. Gurtov. |
| Date: | February 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4015 |
|
Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided. |
|
| |
| RFC 4016 | Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements |
| |
| Authors: | M. Parthasarathy. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4016 |
|
This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol. |
|
| |
| RFC 4017 | Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs |
| |
| Authors: | D. Stanley, J. Walker, B. Aboba. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4017 |
|
The IEEE 802.11i MAC Security Enhancements Amendment makes use ofIEEE 802.1X, which in turn relies on the Extensible AuthenticationProtocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes. |
|
| |
| RFC 4018 | Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) |
| |
| Authors: | M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry. |
| Date: | April 2005 |
| Formats: | txt html json |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4018 |
|
The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the ServiceLocation Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. |
|
| |
| RFC 4019 | RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite |
| |
|
|
This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095. |
|
| |
| RFC 4020 | Early IANA Allocation of Standards Track Code Points |
| |
| Authors: | K. Kompella, A. Zinin. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7120 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4020 |
|
This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication. |
|
| |
| RFC 4021 | Registration of Mail and MIME Header Fields |
| |
|
|
This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864. |
|
| |
| RFC 4022 | Management Information Base for the Transmission Control Protocol (TCP) |
| |
|
|
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 used for implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012. |
|
| |
| RFC 4023 | Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) |
| |
| Authors: | T. Worster, Y. Rekhter, E. Rosen, Ed.. |
| Date: | March 2005 |
| Formats: | txt json html |
| Updated by: | RFC 5332 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4023 |
|
Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic RoutingEncapsulation). Each of these is applicable in some circumstances. |
|
| |
| RFC 4024 | Voice Messaging Client Behaviour |
| |
| Authors: | G. Parsons, J. Maruszak. |
| Date: | July 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4024 |
|
This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message. |
|
| |
| RFC 4025 | A Method for Storing IPsec Keying Material in DNS |
| |
| Authors: | M. Richardson. |
| Date: | March 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4025 |
|
This document describes a new resource record for the Domain NameSystem (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question.
This record replaces the functionality of the sub-type #4 of the KEYResource Record, which has been obsoleted by RFC 3445. |
|
| |
| RFC 4026 | Provider Provisioned Virtual Private Network (VPN) Terminology |
| |
| Authors: | L. Andersson, T. Madsen. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4026 |
|
The widespread interest in provider-provisioned Virtual PrivateNetwork (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first ProviderProvisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services.
To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. |
|
| |
| RFC 4027 | Domain Name System Media Types |
| |
| Authors: | S. Josefsson. |
| Date: | April 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4027 |
|
This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035. |
|
| |
| RFC 4028 | Session Timers in the Session Initiation Protocol (SIP) |
| |
| Authors: | S. Donovan, J. Rosenberg. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4028 |
|
This document defines an extension to the Session Initiation Protocol(SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields:Session-Expires, which conveys the lifetime of the session, andMin-SE, which conveys the minimum allowed value for the session timer. |
|
| |
| RFC 4029 | Scenarios and Analysis for Introducing IPv6 into ISP Networks |
| |
| Authors: | M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola. |
| Date: | March 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4029 |
|
This document describes different scenarios for the introduction ofIPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated.Known challenges are also identified. |
|
| |
| RFC 4030 | The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option |
| |
| Authors: | M. Stapp, T. Lemon. |
| Date: | March 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4030 |
|
The Dynamic Host Configuration Protocol (DHCP) Relay AgentInformation Option (RFC 3046) conveys information between a DHCPRelay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages. |
|
| |
| RFC 4031 | Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) |
| |
| Authors: | M. Carugi, Ed., D. McDysan, Ed.. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4031 |
|
This document provides requirements for Layer 3 Virtual PrivateNetworks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP- based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider. |
|
| |
| RFC 4032 | Update to the Session Initiation Protocol (SIP) Preconditions Framework |
| |
| Authors: | G. Camarillo, P. Kyzivat. |
| Date: | March 2005 |
| Formats: | txt json html |
| Updates: | RFC 3312 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4032 |
|
This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. |
|
| |
| RFC 4033 | DNS Security Introduction and Requirements |
| |
| Authors: | R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. |
| Date: | March 2005 |
| Formats: | txt json html |
| Obsoletes: | RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 |
| Updates: | RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226 |
| Updated by: | RFC 6014, RFC 6840 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4033 |
|
The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that theDNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. |
|
| |
| RFC 4034 | Resource Records for the DNS Security Extensions |
| |
| Authors: | R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. |
| Date: | March 2005 |
| Formats: | txt html json |
| Obsoletes: | RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 |
| Updates: | RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226 |
| Updated by: | RFC 4470, RFC 6014, RFC 6840, RFC 6944, RFC 9077 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4034 |
|
This document is part of a family of documents that describe the DNSSecurity Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.
This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. |
|
| |
| RFC 4035 | Protocol Modifications for the DNS Security Extensions |
| |
| Authors: | R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. |
| Date: | March 2005 |
| Formats: | txt html json |
| Obsoletes: | RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 |
| Updates: | RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226 |
| Updated by: | RFC 4470, RFC 6014, RFC 6840, RFC 8198, RFC 9077, RFC 9520 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4035 |
|
This document is part of a family of documents that describe the DNSSecurity Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.
This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. |
|
| |
| RFC 4036 | Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a set of managed objects for Simple NetworkManagement Protocol (SNMP)-based management of Data-over-CableService Interface Specification (DOCSIS)-compliant Cable ModemTermination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The DifferentiatedServices MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. |
|
| |
| RFC 4037 | Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core |
| |
| Authors: | A. Rousskov. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4037 |
|
This document specifies the core of the Open Pluggable Edge Services(OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCPCore consists of application-agnostic mechanisms essential for efficient support of typical adaptations. |
|
| |
| RFC 4038 | Application Aspects of IPv6 Transition |
| |
| Authors: | M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro. |
| Date: | March 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4038 |
|
As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to developIP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. |
|
| |
| RFC 4039 | Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) |
| |
| Authors: | S. Park, P. Kim, B. Volz. |
| Date: | March 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4039 |
|
This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a2-message exchange rather than the usual 4-message exchange, expediting client configuration. |
|
| |
| RFC 4040 | RTP Payload Format for a 64 kbit/s Transparent Call |
| |
| Authors: | R. Kreuter. |
| Date: | April 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4040 |
|
This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called"Clearmode". It also serves as registration for a related MIME type called "audio/clearmode".
"Clearmode" is a basic feature of VoIP Media Gateways. |
|
| |
| RFC 4041 | Requirements for Morality Sections in Routing Area Drafts |
| |
| Authors: | A. Farrel. |
| Date: | 1 April 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4041 |
|
It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal.
This document specifies a requirement for all new Routing AreaInternet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain. |
|
| |
| RFC 4042 | UTF-9 and UTF-18 Efficient Transformation Formats of Unicode |
| |
| Authors: | M. Crispin. |
| Date: | 1 April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4042 |
|
ISO-10646 defines a large character set called the UniversalCharacter Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions toISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization.
The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet.
This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient. |
|
| |
| RFC 4043 | Internet X.509 Public Key Infrastructure Permanent Identifier |
| |
| Authors: | D. Pinkas, T. Gindin. |
| Date: | May 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4043 |
|
This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used by aCA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed.
The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. |
|
| |
| RFC 4044 | Fibre Channel Management MIB |
| |
|
|
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 information related to the Fibre Channel. |
|
| |
| RFC 4045 | Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP) |
| |
| Authors: | G. Bourdon. |
| Date: | April 2005 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4045 |
|
The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels. |
|
| |
| RFC 4046 | Multicast Security (MSEC) Group Key Management Architecture |
| |
| Authors: | M. Baugher, R. Canetti, L. Dondeti, F. Lindholm. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4046 |
|
This document defines the common architecture for Multicast Security(MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. |
|
| |
| RFC 4047 | MIME Sub-type Registrations for Flexible Image Transport System (FITS) |
| |
| Authors: | S. Allen, D. Wells. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4047 |
|
This document describes the registration of the Multipurpose InternetMail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible ImageTransport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS. |
|
| |
| RFC 4048 | RFC 1888 Is Obsolete |
| |
|
|
This document recommends that RFC 1888, on Open SystemsInterconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. |
|
| |
| RFC 4049 | BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 |
| |
|
|
This document specifies a new ASN.1 type for representing time:BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary- signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. |
|
| |
| RFC 4050 | Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures |
| |
| Authors: | S. Blake-Wilson, G. Karlinger, T. Kobayashi, Y. Wang. |
| Date: | April 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4050 |
|
This document specifies how to use Elliptic Curve Digital SignatureAlgorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. |
|
| |
| RFC 4051 | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
|
A number of Uniform Resource Identifiers (URIs) intended for use withXML Digital Signatures, Encryption, and Canonicalization are defined.These URIs identify algorithms and types of keying information. |
|
| |
| RFC 4052 | IAB Processes for Management of IETF Liaison Relationships |
| |
| Authors: | L. Daigle, Ed., Internet Architecture Board. |
| Date: | April 2005 |
| Formats: | txt html json |
| Also: | BCP 0102 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4052 |
|
This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and otherStandards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. |
|
| |
| RFC 4053 | Procedures for Handling Liaison Statements to and from the IETF |
| |
| Authors: | S. Trowbridge, S. Bradner, F. Baker. |
| Date: | April 2005 |
| Formats: | txt html json |
| Also: | BCP 0103 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 4053 |
|
This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations(SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community.
The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. TheIETF is only obligated to respond if there is an agreed liaison relationship, however. |
|
| |
| RFC 4054 | Impairments and Other Constraints on Optical Layer Routing |
| |
| Authors: | J. Strand, Ed., A. Chiu, Ed.. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4054 |
|
Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS). Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1)Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints. |
|
| |
| RFC 4055 | Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric EncryptionPadding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public KeyInfrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. |
|
| |
| RFC 4056 | Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS) |
| |
| Authors: | J. Schaad. |
| Date: | June 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4056 |
|
This document specifies the conventions for using the RSASSA-PSS (RSAProbabilistic Signature Scheme) digital signature algorithm with theCryptographic Message Syntax (CMS). |
|
| |
| RFC 4057 | IPv6 Enterprise Network Scenarios |
| |
| Authors: | J. Bound, Ed.. |
| Date: | June 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4057 |
|
This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios.Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment.The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. |
|
| |
| RFC 4058 | Protocol for Carrying Authentication for Network Access (PANA) Requirements |
| |
| Authors: | A. Yegin, Ed., Y. Ohba, R. Penno, G. Tsirtsis, C. Wang. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4058 |
|
It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of theAAA infrastructure. |
|
| |
| RFC 4059 | Internet X.509 Public Key Infrastructure Warranty Certificate Extension |
| |
| Authors: | D. Linsenbardt, S. Pontius, A. Sturgeon. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4059 |
|
This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension. |
|
| |
| RFC 4060 | RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding |
| |
| Authors: | Q. Xie, D. Pearce. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4060 |
|
This document specifies RTP payload formats for encapsulatingEuropean Telecommunications Standards Institute (ETSI) EuropeanStandard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSRExtended Front-end (XFE), and ES 202 212 DSR Extended AdvancedFront-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems. |
|
| |
| RFC 4061 | Benchmarking Basic OSPF Single Router Control Plane Convergence |
| |
| Authors: | V. Manral, R. White, A. Shaikh. |
| Date: | April 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4061 |
|
This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance.
NOTE: In this document, the word "convergence" relates to single router control plane convergence only. |
|
| |
| RFC 4062 | OSPF Benchmarking Terminology and Concepts |
| |
| Authors: | V. Manral, R. White, A. Shaikh. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4062 |
|
This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere(and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol. |
|
| |
| RFC 4063 | Considerations When Using Basic OSPF Convergence Benchmarks |
| |
| Authors: | V. Manral, R. White, A. Shaikh. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4063 |
|
This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested. |
|
| |
| RFC 4064 | Experimental Message, Extensions, and Error Codes for Mobile IPv4 |
| |
| Authors: | A. Patel, K. Leung. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4064 |
|
Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements toMobile IPv4 messages before a formal standards proposal is issued. |
|
| |
| RFC 4065 | Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations |
| |
| Authors: | J. Kempf. |
| Date: | July 2005 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4065 |
|
The Seamoby Candidate Access Router Discovery (CARD) protocol and theContext Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, StreamControl Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options.This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols. |
|
| |
| RFC 4066 | Candidate Access Router Discovery (CARD) |
| |
| Authors: | M. Liebsch, Ed., A. Singh, Ed., H. Chaskar, D. Funato, E. Shim. |
| Date: | July 2005 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4066 |
|
To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery ofCARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. |
|
| |
| RFC 4067 | Context Transfer Protocol (CXTP) |
| |
| Authors: | J. Loughney, Ed., M. Nakhjiri, C. Perkins, R. Koodli. |
| Date: | July 2005 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4067 |
|
This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node. |
|
| |
| RFC 4068 | Fast Handovers for Mobile IPv6 |
| |
|
|
Mobile IPv6 enables a Mobile Node to maintain its connectivity to theInternet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and BindingUpdate, is often unacceptable to real-time traffic such as Voice overIP. Reducing the handover latency could be beneficial to non-real- time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. |
|
| |
| RFC 4069 | Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding |
| |
| Authors: | M. Dodge, B. Ray. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4069 |
|
This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed DigitalSubscriber Line (VDSL) interfaces using Single Carrier Modulation(SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB,RFC 3728, which handles line code independent objects. |
|
| |
| RFC 4070 | Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding |
| |
| Authors: | M. Dodge, B. Ray. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4070 |
|
This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed DigitalSubscriber Line (VDSL) interfaces using Multiple Carrier Modulation(MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB,RFC 3728, which handles line code independent objects. |
|
| |
| RFC 4071 | Structure of the IETF Administrative Support Activity (IASA) |
| |
|
|
This document describes the structure of the IETF AdministrativeSupport Activity (IASA) as an activity housed within the InternetSociety (ISOC). It defines the roles and responsibilities of theIETF Administrative Oversight Committee (IAOC), the IETFAdministrative Director (IAD), and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IAOC. |
|
| |
| RFC 4072 | Diameter Extensible Authentication Protocol (EAP) Application |
| |
|
|
The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server. |
|
| |
| RFC 4073 | Protecting Multiple Contents with the Cryptographic Message Syntax (CMS) |
| |
| Authors: | R. Housley. |
| Date: | May 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4073 |
|
This document describes a convention for using the CryptographicMessage Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content. |
|
| |
| RFC 4074 | Common Misbehavior Against DNS Queries for IPv6 Addresses |
| |
| Authors: | Y. Morishita, T. Jinmei. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4074 |
|
There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can blockIPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects. |
|
| |
| RFC 4075 | Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 |
| |
| Authors: | V. Kalusivalingam. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4075 |
|
This document describes a new DHCPv6 option for passing a list ofSimple Network Time Protocol (SNTP) server addresses to a client. |
|
| |
| RFC 4076 | Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | T. Chown, S. Venaas, A. Vijayabhaskar. |
| Date: | May 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4076 |
|
IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and statelessDHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. |
|
| |
| RFC 4077 | A Negative Acknowledgement Mechanism for Signaling Compression |
| |
| Authors: | A.B. Roach. |
| Date: | May 2005 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4077 |
|
This document describes a mechanism that allows Signaling Compression(SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. |
|
| |
| RFC 4078 | The TV-Anytime Content Reference Identifier (CRID) |
| |
| Authors: | N. Earnshaw, S. Aoki, A. Ashley, W. Kameyama. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4078 |
|
The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet.
The initial intended application is as an embedded link within scheduled programme description metadata that can be used by the home user or agent to associate a programme selection with the corresponding programme location information for subsequent automatic acquisition.
This document reproduces the TV-Anytime CRID definition found in theTV-Anytime content referencing specification, and is published as anRFC for ease of access and registration with the Internet AssignedNumbers Authority (IANA). |
|
| |
| RFC 4079 | A Presence Architecture for the Distribution of GEOPRIV Location Objects |
| |
| Authors: | J. Peterson. |
| Date: | July 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4079 |
|
GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation ofGEOPRIV. |
|
| |
| RFC 4080 | Next Steps in Signaling (NSIS): Framework |
| |
| Authors: | R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4080 |
|
The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.
This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application. |
|
| |
| RFC 4081 | Security Threats for Next Steps in Signaling (NSIS) |
| |
| Authors: | H. Tschofenig, D. Kroeselberg. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4081 |
|
This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite. |
|
| |
| RFC 4082 | Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction |
| |
| Authors: | A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe. |
| Date: | June 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4082 |
|
This document introduces Timed Efficient Stream Loss-tolerantAuthentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.
This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. |
|
| |
| RFC 4083 | Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP) |
| |
| Authors: | M. Garcia-Martin. |
| Date: | May 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4083 |
|
The 3rd-Generation Partnership Project (3GPP) has selected SessionInitiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part ofRelease 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP forRelease 5 of the 3GPP IMS in cellular networks. |
|
| |
| RFC 4084 | Terminology for Describing Internet Connectivity |
| |
|
|
As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, the effort to distinguish between these services has caused considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. |
|
| |
| RFC 4085 | Embedding Globally-Routable Internet Addresses Considered Harmful |
| |
|
|
This document discourages the practice of embedding references to unique, globally-routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives.This document is intended to clarify best current practices in this regard. |
|
| |
| RFC 4086 | Randomness Requirements for Security |
| |
|
|
Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo- security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.
Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose.It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. |
|
| |
| RFC 4087 | IP Tunnel MIB |
| |
|
|
This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extensionMIB modules may be designed for managing security-specific objects.This MIB module does not support tunnels over non-IP networks.Management of such tunnels may be supported by other MIB modules.This memo obsoletes RFC 2667. |
|
| |
| RFC 4088 | Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | D. Black, K. McCloghrie, J. Schoenwaelder. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4088 |
|
The Simple Network Management Protocol (SNMP) and the InternetStandard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access(including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform ResourceIdentifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.
This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances. |
|
| |
| RFC 4089 | IAB and IESG Recommendation for IETF Administrative Restructuring |
| |
| Authors: | S. Hollenbeck, Ed., IAB and IESG. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4089 |
|
This document describes a joint recommendation of the InternetArchitecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force.The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record. |
|
| |
| RFC 4090 | Fast Reroute Extensions to RSVP-TE for LSP Tunnels |
| |
|
|
This document defines RSVP-TE extensions to establish backup label- switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.
Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. |
|
| |
| RFC 4091 | The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework |
| |
| Authors: | G. Camarillo, J. Rosenberg. |
| Date: | June 2005 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5245 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4091 |
|
This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream. |
|
| |
| RFC 4092 | Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, J. Rosenberg. |
| Date: | June 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5245 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4092 |
|
This document describes how to use the Alternative Network AddressTypes (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT. |
|
| |
| RFC 4093 | Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways |
| |
| Authors: | F. Adrangi, Ed., H. Levkowetz, Ed.. |
| Date: | August 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4093 |
|
Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions. |
|
| |
| RFC 4094 | Analysis of Existing Quality-of-Service Signaling Protocols |
| |
| Authors: | J. Manner, X. Fu. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4094 |
|
This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area. |
|
| |
| RFC 4095 | Attaching Meaning to Solicitation Class Keywords |
| |
| Authors: | C. Malamud. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4095 |
|
This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the NoSoliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new "No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender.
This document specifies an application based on the DynamicDelegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the"org.example.adv" solicitation class keyword. |
|
| |
| RFC 4096 | Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best |
| |
| Authors: | C. Malamud. |
| Date: | May 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4096 |
|
This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. |
|
| |
| RFC 4097 | Middlebox Communications (MIDCOM) Protocol Evaluation |
| |
|
|
This document provides an evaluation of the applicability of SNMP(Simple Network Management Protocol), RSIP (Realm Specific InternetProtocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. |
|
| |
| RFC 4098 | Terminology for Benchmarking BGP Device Convergence in the Control Plane |
| |
| Authors: | H. Berkowitz, E. Davies, Ed., S. Hares, P. Krishnaswamy, M. Lepp. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4098 |
|
This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. |
|
