| |
| RFC 2600 | Internet Official Protocol Standards |
| |
| Authors: | J. Reynolds, R. Braden. |
| Date: | March 2000 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2500 |
| Obsoleted by: | RFC 2700 |
| Status: | HISTORIC |
|
This memo is published by the RFC Editor in accordance with Section 2.1 of "The Internet Standards Process -- Revision 3", RFC 2026, which specifies the rules and procedures by which all Internet standards are set. This memo is prepared by the RFC Editor for the IESG and IAB. Please see http://www.rfc-editor.org for later updates to this document. [STANDARDS-TRACK] |
|
| |
| RFC 2601 | ILMI-Based Server Discovery for ATMARP |
| |
| Authors: | M. Davison. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers. |
|
| |
| RFC 2602 | ILMI-Based Server Discovery for MARS |
| |
| Authors: | M. Davison. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers. |
|
| |
| RFC 2603 | ILMI-Based Server Discovery for NHRP |
| |
| Authors: | M. Davison. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers. |
|
| |
| RFC 2604 | Wireless Device Configuration (OTASP/OTAPA) via ACAP |
| |
| Authors: | R. Gellens. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 2636 |
| Status: | INFORMATIONAL |
|
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol. |
|
| |
| RFC 2605 | Directory Server Monitoring MIB |
| |
| Authors: | G. Mansfield, S. Kille. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1567 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1567, "X.500 Directory Monitoring MIB". This memo extends that specification to a more generic MIB for monitoring one or more directory servers each of which may support multiple access protocols. The MIB defined in this memo will be used in conjunction with the NETWORK-SERVICES-MIB [19] for monitoringDirectory Servers. |
|
| |
| RFC 2606 | Reserved Top Level DNS Names |
| |
| Authors: | D. Eastlake 3rd, A. Panitz. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Also: | BCP 0032 |
| Status: | BEST CURRENT PRACTICE |
|
To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. |
|
| |
| RFC 2607 | Proxy Chaining and Policy Implementation in Roaming |
| |
| Authors: | B. Aboba, J. Vollbrecht. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community. |
|
| |
| RFC 2608 | Service Location Protocol, Version 2 |
| |
| Authors: | E. Guttman, C. Perkins, J. Veizades, M. Day. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Updates: | RFC 2165 |
| Updated by: | RFC 3224 |
| Status: | PROPOSED STANDARD |
|
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. |
|
| |
| RFC 2609 | Service Templates and Service: Schemes |
| |
| Authors: | E. Guttman, C. Perkins, J. Kempf. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Updates: | RFC 2165 |
| Status: | PROPOSED STANDARD |
|
The "service:" URL scheme name is used to define URLs (called"service: URLs" in this document) that are primarily intended to be used by the Service Location Protocol in order to distribute service access information. These schemes provide an extensible framework for client-based network software to obtain configuration information required to make use of network services. When registering a service: URL, the URL is accompanied by a set of well-defined attributes which define the service. These attributes convey configuration information to client software, or service characteristics meaningful to end users.
This document describes a formal procedure for defining and standardizing new service types and attributes for use with the"service:" scheme. The formal descriptions of service types and attributes are templates that are human and machine understandable.They SHOULD be used by administrative tools to parse service registration information and by client applications to provide localized translations of service attribute strings. |
|
| |
| RFC 2610 | DHCP Options for Service Location Protocol |
| |
| Authors: | C. Perkins, E. Guttman. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network.Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents. |
|
| |
| RFC 2611 | URN Namespace Definition Mechanisms |
| |
| Authors: | L. Daigle, D. van Gulik, R. Iannella, P. Falstrom. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3406 |
| Also: | BCP 0033 |
| Status: | BEST CURRENT PRACTICE |
|
The URN WG has defined a syntax for Uniform Resource Names (URNs)[RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFC2168, RFC2169]). The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN "namespaces". |
|
| |
| RFC 2612 | The CAST-256 Encryption Algorithm |
| |
| Authors: | C. Adams, J. Gilchrist. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
There is always a desire in the Internet community for unencumbered encryption algorithms with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.
This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A). |
|
| |
| RFC 2613 | Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0 |
| |
| Authors: | R. Waterman, B. Lahaye, D. Romascanu, S. Waldbusser. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | DRAFT STANDARD |
|
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 managing remote network monitoring devices in switched networks environments. |
|
| |
| RFC 2614 | An API for Service Location |
| |
| Authors: | J. Kempf, E. Guttman. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
The Service Location Protocol (SLP) provides a new way for clients to dynamically discovery network services. With SLP, it is simple to offer highly available services that require no user configuration or assistance from network administrators prior to use. This document describes standardized APIs for SLP in C and Java. The APIs are modular and are designed to allow implementations to offer just the feature set needed. In addition, standardized file formats for configuration and serialized registrations are defined, allowing SLP agents to set network and other parameters in a portable way. The serialized file format allows legacy services to be registered withSLP directory agents in cases where modifying the legacy service program code is difficult or impossible, and to portably exchange a registration database. |
|
| |
| RFC 2615 | PPP over SONET/SDH |
| |
| Authors: | A. Malis, W. Simpson. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1619 |
| Status: | PROPOSED STANDARD |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Synchronous OpticalNetwork (SONET) and Synchronous Digital Hierarchy (SDH) circuits.
This document replaces and obsoletes RFC 1619. See section 7 for a summary of the changes from RFC 1619. |
|
| |
| RFC 2616 | Hypertext Transfer Protocol -- HTTP/1.1 |
| |
| Authors: | R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. |
| Date: | June 1999 |
| Formats: | txt pdf ps |
| Obsoletes: | RFC 2068 |
| Updated by: | RFC 2817 |
| Status: | DRAFT STANDARD |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33]. |
|
| |
| RFC 2617 | HTTP Authentication: Basic and Digest Access Authentication |
| |
| Authors: | J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2069 |
| Status: | DRAFT STANDARD |
|
"HTTP/1.0", includes the specification for a Basic AccessAuthentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext.
This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as "DigestAccess Authentication". It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified byRFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended.
Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use. |
|
| |
| RFC 2618 | RADIUS Authentication Client MIB |
| |
| Authors: | B. Aboba, G. Zorn. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4668 |
| Status: | PROPOSED STANDARD |
|
This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. |
|
| |
| RFC 2619 | RADIUS Authentication Server MIB |
| |
| Authors: | G. Zorn, B. Aboba. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4669 |
| Status: | PROPOSED STANDARD |
|
This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers. |
|
| |
| RFC 2620 | RADIUS Accounting Client MIB |
| |
| Authors: | B. Aboba, G. Zorn. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4670 |
| Status: | INFORMATIONAL |
|
This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients. |
|
| |
| RFC 2621 | RADIUS Accounting Server MIB |
| |
| Authors: | G. Zorn, B. Aboba. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4671 |
| Status: | INFORMATIONAL |
|
This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers. |
|
| |
| RFC 2622 | Routing Policy Specification Language (RPSL) |
| |
| Authors: | C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2280 |
| Updated by: | RFC 4012 |
| Status: | PROPOSED STANDARD |
|
RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at theAutonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. |
|
| |
| RFC 2623 | NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 |
| |
| Authors: | M. Eisler. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how theVersion 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. This memorandum is provided so that people can write compatible implementations. |
|
| |
| RFC 2624 | NFS Version 4 Design Considerations |
| |
| Authors: | S. Shepler. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
The main task of the NFS version 4 working group is to create a protocol definition for a distributed file system that focuses on the following items: improved access and good performance on theInternet, strong security with negotiation built into the protocol, better cross-platform interoperability, and designed for protocol extensions. NFS version 4 will owe its general design to the previous versions of NFS. It is expected, however, that many features will be quite different in NFS version 4 than previous versions to facilitate the goals of the working group and to address areas that NFS version 2 and 3 have not.
This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. Based on this investigation the working group will decide the features of the new protocol based on the cost and benefits within the specific feature areas. |
|
| |
| RFC 2625 | IP and ARP over Fibre Channel |
| |
| Authors: | M. Rajagopal, R. Bhagwat, W. Rickard. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4338 |
| Status: | PROPOSED STANDARD |
|
Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small ComputerSystem Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards[3] do not adequately specify how IP packets may be transported overFC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and AddressResolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution. |
|
| |
| RFC 2626 | The Internet and the Millennium Problem (Year 2000) |
| |
| Authors: | P. Nesser II. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols.This investigation only targeted the protocols as documented in theRequest For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost allInternet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. |
|
| |
| RFC 2627 | Key Management for Multicast: Issues and Architectures |
| |
| Authors: | D. Wallner, E. Harder, R. Agee. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals [1,2,4]. The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group. |
|
| |
| RFC 2628 | Simple Cryptographic Program Interface (Crypto API) |
| |
| Authors: | V. Smyslov. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document describes a simple Application Program Interface to cryptographic functions. The main purpose of such an interface is to separate cryptographic libraries from internet applications, thus allowing an independent development of both. It can be used in various internet applications such as [IPsec], [ISAKMP], [IKE],[TLS]. |
|
| |
| RFC 2629 | Writing I-Ds and RFCs using XML |
| |
| Authors: | M. Rose. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This memo presents a technique for using XML (Extensible MarkupLanguage) as a source format for documents in the Internet-Drafts(I-Ds) and Request for Comments (RFC) series. |
|
| |
| RFC 2630 | Cryptographic Message Syntax |
| |
|
|
This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.
The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate attribute certificate transfer and key agreement techniques for key management. |
|
| |
| RFC 2631 | Diffie-Hellman Key Agreement Method |
| |
| Authors: | E. Rescorla. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary amount of keying material is provided. The resulting keying material is used as a symmetric encryption key. The Diffie-Hellman variant described requires the recipient to have a certificate, but the originator may have a static key pair (with the public key placed in a certificate) or an ephemeral key pair. |
|
| |
| RFC 2632 | S/MIME Version 3 Certificate Handling |
| |
| Authors: | B. Ramsdell, Ed.. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3850 |
| Status: | PROPOSED STANDARD |
|
S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK] |
|
| |
| RFC 2633 | S/MIME Version 3 Message Specification |
| |
| Authors: | B. Ramsdell, Ed.. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3851 |
| Status: | PROPOSED STANDARD |
|
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK] |
|
| |
| RFC 2634 | Enhanced Security Services for S/MIME |
| |
| Authors: | P. Hoffman, Ed.. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Updated by: | RFC 5035 |
| Status: | PROPOSED STANDARD |
|
This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK] |
|
| |
| RFC 2635 | DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) |
| |
| Authors: | S. Hambridge, A. Lunde. |
| Date: | June 1999 |
| Formats: | txt pdf |
| Also: | FYI 0035 |
| Status: | INFORMATIONAL |
|
This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. It gives a set of guidelines for dealing with unsolicited mail for users, for system administrators, news administrators, and mailing list managers. It also makes suggestions Internet Service Providers might follow. |
|
| |
| RFC 2636 | Wireless Device Configuration (OTASP/OTAPA) via ACAP |
| |
| Authors: | R. Gellens. |
| Date: | July 1999 |
| Formats: | txt pdf ps |
| Obsoletes: | RFC 2604 |
| Status: | INFORMATIONAL |
|
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol. |
|
| |
| RFC 2637 | Point-to-Point Tunneling Protocol (PPTP) |
| |
| Authors: | K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn. |
| Date: | July 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document specifies a protocol which allows the Point to PointProtocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network AccessServers (NAS) and support Virtual Private Networks (VPNs). The PPTPNetwork Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP AccessConcentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit- switched connections. PPTP uses an enhanced GRE (Generic RoutingEncapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. |
|
| |
| RFC 2638 | A Two-bit Differentiated Services Architecture for the Internet |
| |
| Authors: | K. Nichols, V. Jacobson, L. Zhang. |
| Date: | July 1999 |
| Formats: | txt pdf ps |
| Status: | INFORMATIONAL |
|
This document was originally submitted as an internet draft inNovember of 1997. As one of the documents predating the formation of the IETF's Differentiated Services Working Group, many of the ideas presented here, in concert with Dave Clark's subsequent presentation to the December 1997 meeting of the IETF Integrated Services WorkingGroup, were key to the work which led to RFCs 2474 and 2475 and the section on allocation remains a timely proposal. For this reason, and to provide a reference, it is being submitted in its original form.The forwarding path portion of this document is intended as a record of where we were at in late 1997 and not as an indication of future direction.
The postscript version of this document includes Clark's slides as an appendix. The postscript version of this document also includes many figures that aid greatly in its readability. |
|
| |
| RFC 2639 | Internet Printing Protocol/1.0: Implementer's Guide |
| |
| Authors: | T. Hastings, C. Manros. |
| Date: | July 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3196 |
| Status: | INFORMATIONAL |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. TheJob supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It also defines the encoding rules for a new Internet media type called"application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2640 | Internationalization of the File Transfer Protocol |
| |
| Authors: | B. Curtin. |
| Date: | July 1999 |
| Formats: | txt pdf |
| Updates: | RFC 0959 |
| Status: | PROPOSED STANDARD |
|
The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC1123 Section 4 [RFC1123], is one of the oldest and widely used protocols on the Internet. The protocol's primary character set, 7 bit ASCII, has served the protocol well through the early growth years of the Internet. However, as the Internet becomes more global, there is a need to support character sets beyond 7 bit ASCII.
This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending theFTP specification and giving recommendations for proper internationalization support. |
|
| |
| RFC 2641 | Cabletron's VlanHello Protocol Specification Version 4 |
| |
| Authors: | D. Hamilton, D. Ruffen. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
The VlanHello protocol is part of the InterSwitch Message Protocol(ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric. |
|
| |
| RFC 2642 | Cabletron's VLS Protocol Specification |
| |
| Authors: | L. Kane. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
The Virtual LAN Link State Protocol (VLSP) is part of the InterSwitchMessage Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. VLSP is used to determine and maintain a fully connected mesh topology graph of the switch fabric. Each switch maintains an identical database describing the topology. Call-originating switches use the topology database to determine the path over which to route a call connection.
VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. |
|
| |
| RFC 2643 | Cabletron's SecureFast VLAN Operational Model |
| |
| Authors: | D. Ruffen, T. Len, J. Yanacek. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages. |
|
| |
| RFC 2644 | Changing the Default for Directed Broadcasts in Routers |
| |
| Authors: | D. Senie. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Updates: | RFC 1812 |
| Also: | BCP 0034 |
| Status: | BEST CURRENT PRACTICE |
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. This memo provides information for the Internet community. |
|
| |
| RFC 2645 | ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses |
| |
| Authors: | R. Gellens. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK] |
|
| |
| RFC 2646 | The Text/Plain Format Parameter |
| |
| Authors: | R. Gellens, Ed.. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 3676 |
| Updates: | RFC 2046 |
| Status: | PROPOSED STANDARD |
|
This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK] |
|
| |
| RFC 2647 | Benchmarking Terminology for Firewall Performance |
| |
| Authors: | D. Newman. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK] |
|
| |
| RFC 2648 | A URN Namespace for IETF Documents |
| |
| Authors: | R. Moats. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
A system for Uniform Resource Names (URNs) must be capable of supporting new naming systems. As an example of proposing a new namespace, this document proposes the "ietf" namespace. This namespace consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor, the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences, and the Internet Drafts published by the Internet Drafts Editor. Both the current URN framework andURN syntax support this namespace. |
|
| |
| RFC 2649 | An LDAP Control and Schema for Holding Operation Signatures |
| |
| Authors: | B. Greenblatt, P. Richard. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
In many environments clients require the ability to validiate the source and integrity of information provided by the directory. This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines anLDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. Both client and server based signatures are supported. An object class for subsequent retrieval are "journal entries" is also defined. This document specifies LDAP v3 controls that enable this functionality. It also defines an LDAP v3 schema that allows for subsequent browsing of the journal information. |
|
| |
| RFC 2650 | Using RPSL in Practice |
| |
| Authors: | D. Meyer, J. Schmitz, C. Orange, M. Prior, C. Alaettinoglu. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This document is a tutorial on using the Routing Policy SpecificationLanguage (RPSL) to describe routing policies in the Internet RoutingRegistry (IRR). We explain how to specify various routing policies and configurations using RPSL, how to register these policies in theIRR, and how to analyze them using the routing policy analysis tools, for example to generate vendor specific router configurations. |
|
| |
| RFC 2651 | The Architecture of the Common Indexing Protocol (CIP) |
| |
| Authors: | J. Allen, M. Mealling. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. Query routing is the process of redirecting and replicating queries through a distributed database system towards servers holding the desired results. This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices. |
|
| |
| RFC 2652 | MIME Object Definitions for the Common Indexing Protocol (CIP) |
| |
| Authors: | J. Allen, M. Mealling. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. The protocol is comprised of several MIME objects being passed from server to server. This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type. |
|
| |
| RFC 2653 | CIP Transport Protocols |
| |
| Authors: | J. Allen, P. Leach, R. Hedberg. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP.The objects themselves are defined in [CIP-MIME] and the overall CIP architecture is defined in [CIP-ARCH]. |
|
| |
| RFC 2654 | A Tagged Index Object for use in the Common Indexing Protocol |
| |
| Authors: | R. Hedberg, B. Greenblatt, R. Moats, M. Wahl. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the CommonIndexing Protocol. It is assumed that the structures defined here can be used by X.500 DSAs, LDAP servers, Whois++ servers, CSO Ph servers and many others. |
|
| |
| RFC 2655 | CIP Index Object Format for SOIF Objects |
| |
| Authors: | T. Hardie, M. Bowman, D. Hardy, M. Schwartz, D. Wessels. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2656 | Registration Procedures for SOIF Template Types |
| |
| Authors: | T. Hardie. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
The Summary Object Interchange Format [Ref. 1] was first defined by the Harvest Project [Ref 2.] in January 1994. SOIF was derived from a combination of the Internet Anonymous FTP Archives IETF WorkingGroup (IAFA) templates [Ref 3.] and the BibTeX bibliography format[Ref 4.]. The combination was originally noted for its advantages of providing a convenient and intuitive way for delimiting objects within a stream, and setting apart the URL for easy object access or invocation, while still preserving compatibility with IAFA templates.
SOIF uses named template types to indicate the attributes which may be contained within a particular summary object. Within the context of a single application, private agreement on the definition of template types has been adequate. As SOIF objects are moved among applications, however, the need for standard, well-specified, and easily identifiable template types increases. This need is particularly intense in the context of query referral, where knowledge of an attribute's definition and the allowed data types for specific values is crucial. For a discussion of this in the context of the Common Indexing Protocol, see [Ref. 1].
The registration procedure described in this document is specific toSOIF template types. There is ongoing work within the IETF to specify a more generic schema registration facility[Ref. 5]. It is not yet clear whether the results of that work will encompass the ability to register entities like SOIF template types. If it does so, the registration of SOIF template types may be shifted to that method and registry. Should that occur, appropriate pointers will be created in cooperation with the Registrar to ensure that no registrations are lost. |
|
| |
| RFC 2657 | LDAPv2 Client vs |
| |
| Authors: | the Index Mesh. R. Hedberg. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
LDAPv2 clients as implemented according to RFC 1777 [1] have no notion on referral. The integration between such a client and anIndex Mesh, as defined by the Common Indexing Protocol [2], heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. |
|
| |
| RFC 2658 | RTP Payload Format for PureVoice(tm) Audio |
| |
| Authors: | K. McKay. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK] |
|
| |
| RFC 2659 | Security Extensions For HTML |
| |
| Authors: | E. Rescorla, A. Schiffman. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. S-HTTP, as described by RFC 2660, contains the concept of negotiation headers which reflect the potential receiver of a message's preferences as to which crypto- graphic enhancements should be applied to the message. This document describes a syntax for binding these negotiation parameters to HTML anchors.
1. Introduction
2. Anchor Attributes
We define the following new anchor (and form submission) attributes:
DN -- The distinguished name of the principal for whom the request should be encrypted when dereferencing the anchor's url.This need not be specified, but failure to do so runs the risk that the client will be unable to determine the DN and therefore will be unable to encrypt. This should be specified in the form of RFC1485, using SGML quoting conventions as needed.
NONCE -- A free-format string (appropriately SGML quoted) which is to be included in a SHTTP-Nonce: header (after SGML quoting is removed) when the anchor is dereferenced.
CRYPTOPTS -- Cryptographic option information as described in
[SHTTP]. Specifically, the <cryptopt-list&rt; production. |
|
| |
| RFC 2660 | The Secure HyperText Transfer Protocol |
| |
| Authors: | E. Rescorla, A. Schiffman. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | EXPERIMENTAL |
|
This memo describes a syntax for securing messages sent using theHypertext Transfer Protocol (HTTP), which forms the basis for theWorld Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin.
The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction. |
|
| |
| RFC 2661 | Layer Two Tunneling Protocol "L2TP" |
| |
| Authors: | W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document describes the Layer Two Tunneling Protocol (L2TP). STD51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications. |
|
| |
| RFC 2662 | Definitions of Managed Objects for the ADSL Lines |
| |
| Authors: | G. Bathrick, F. Ly. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK] |
|
| |
| RFC 2663 | IP Network Address Translator (NAT) Terminology and Considerations |
| |
| Authors: | P. Srisuresh, M. Holdrege. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. |
|
| |
| RFC 2664 | FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions |
| |
| Authors: | R. Plzak, A. Wells, E. Krol. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 1594 |
| Also: | FYI 0004 |
| Status: | INFORMATIONAL |
|
This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. Unlike its predecessors, this edition seeks to answer the general questions that an unsophisticated consumer would ask as opposed to the more pointed questions of a more technically sophisticated Internet user. Those desiring a more in-depth discussion are directed to FYI 7 that deals with intermediate and advanced Q/A topics. A conscious effort has been made to keep this memo brief but at the same time provide the new user with enough information to generally understand theInternet. |
|
| |
| RFC 2665 | Definitions of Managed Objects for the Ethernet-like Interface Types |
| |
| Authors: | J. Flick, J. Johnson. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2358 |
| Obsoleted by: | RFC 3635 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2358, "Definitions of Managed Objects for theEthernet-like Interface Types". This memo extends that specification by including management information useful for the management of 1000Mb/s and full-duplex Ethernet interfaces.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2666 | Definitions of Object Identifiers for Identifying Ethernet Chip Sets |
| |
| Authors: | J. Flick. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | INFORMATIONAL |
|
This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. In particular, it contains registered OID values for use with the dot3StatsEtherChipSet object in the EtherLike-MIB [16]. These registrations have been split from [16] into a separate document for maintenance purposes. |
|
| |
| RFC 2667 | IP Tunnel MIB |
| |
| Authors: | D. Thaler. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4087 |
| Status: | PROPOSED STANDARD |
|
This memo defines a Management Information Base (MIB) 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 networks. [STANDARDS-TRACK] |
|
| |
| RFC 2668 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
| Authors: | A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2239 |
| Obsoleted by: | RFC 3636 |
| Status: | PROPOSED STANDARD |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2239, "Definitions of Managed Objects forIEEE 802.3 Medium Attachment Units (MAUs) using SMIv2". This memo extends that specification by including management information useful for the management of 1000 Mb/s MAUs.
Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology. |
|
| |
| RFC 2669 | DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems |
| |
| Authors: | M. St. Johns, Ed.. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4639 |
| Status: | PROPOSED STANDARD |
|
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 basic set of managed objects for SNMP- based management of DOCSIS 1.0 compliant Cable Modems and Cable ModemTermination Systems.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. |
|
| |
| RFC 2670 | Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces |
| |
| Authors: | M. St. Johns, Ed.. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4546 |
| Status: | PROPOSED STANDARD |
|
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 basic set of managed objects for SNMP- based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects are consistent with theSNMP framework and existing SNMP standards.
This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. |
|
| |
| RFC 2671 | Extension Mechanisms for DNS (EDNS0) |
| |
| Authors: | P. Vixie. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Status: | PROPOSED STANDARD |
|
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. |
|
| |
| RFC 2672 | Non-Terminal DNS Name Redirection |
| |
| Authors: | M. Crawford. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Updated by: | RFC 4592 |
| Status: | PROPOSED STANDARD |
|
This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK] |
|
| |
| RFC 2673 | Binary Labels in the Domain Name System |
| |
|
|
This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK] |
|
| |
| RFC 2674 | Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions |
| |
| Authors: | E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoleted by: | RFC 4363 |
| Status: | PROPOSED STANDARD |
|
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 two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MACBridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'EnhancedMulticast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs.
Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes severalMIB modules in a manner that is compliant to the SMIv2 [V2SMI].
This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent)RFC 1525 [SBRIDGEMIB]. |
|
| |
| RFC 2675 | IPv6 Jumbograms |
| |
| Authors: | D. Borman, S. Deering, R. Hinden. |
| Date: | August 1999 |
| Formats: | txt pdf |
| Obsoletes: | RFC 2147 |
| Status: | PROPOSED STANDARD |
|
A "jumbogram" is an IPv6 packet containing a payload longer than65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms.
Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. |
|
| |
| RFC 2676 | QoS Routing Mechanisms and OSPF Extensions |
| |
|
