Delegated Path Validation and Delegated Path Discovery Protocol Requirements
This document specifies the requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) for Public Key Certificates. It also specifies the requirements for DPV and DPD policy management.
EtherIP: Tunneling Ethernet Frames in IP Datagrams
This document describes EtherIP, an early tunneling protocol, to provide informational and historical context for the assignment of IP protocol 97. EtherIP tunnels Ethernet and IEEE 802.3 media access control frames in IP datagrams so that non-IP traffic can traverse an IP internet. The protocol is very lightweight, and it does not provide protection against infinite loops.
This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for 'source filtering', that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specif…
This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and regis…
Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network
In IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly. In some cases, the host may establish certain routing-related services on subnets that are left behind when the host moves. Examples of such services are AAA, header compression, and QoS. In order for the host to obtain those services on the new subnet, the host m…
Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies
The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. …
Session Initiation Protocol for Telephones (SIP-T): Context and Architectures
RFC 3372 описывает SIP-T как набор механизмов для сопряжения традиционной телефонной сигнализации с SIP в точках взаимодействия PSTN и VoIP-сетей. Документ классифицирует сценарии прохождения вызовов между PSTN-шлюзами и SIP-конечными точками, а также роли инициатора, терминатора и промежуточных узлов. Для сохранения функциональной прозрачности ISUP применяется инкапсуляция ISUP в SIP, а для маршр…
Layer Two Tunneling Protocol "L2TP" Management Information Base
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 networks using Layer 2 Tunneling Protocol.
This document describes several cryptographic algorithms for use with the Cryptographic Message Syntax (CMS) [CMS]. The CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents.
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages.
The 'go' URI Scheme for the Common Name Resolution Protocol
This document defines a URI scheme, 'go:' to be used with the Common Name Resolution Protocol. Specifically it lays out the syntactic components and how those components are used by URI Resolution to find the available transports for a CNRP service. Care should be taken with several of the URI components because, while they may look like components found in other URI schemes, they often do not act…
People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and type than URLs. Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable for their resources are being used elsewhere and so are unavaila…
Advice to link designers on link Automatic Repeat reQuest (ARQ)
RFC 3366 предоставляет рекомендации разработчикам цифрового коммуникационного оборудования и протоколов канального уровня, использующих ARQ для поддержки IP-трафика. ARQ может уменьшать потери кадров, но повторные передачи увеличивают задержку и джиттер; их эффекты накапливаются на нескольких звеньях пути. При невозможности надёжно классифицировать потоки обычно предпочтительны низкая настойчивост…
Strong Security Requirements for Internet Engineering Task Force Standard Protocols
RFC 3365 фиксирует консенсус IETF: стандартные протоколы IETF ОБЯЗАНЫ (MUST) использовать надлежащие сильные механизмы безопасности. Документ обосновывает это требование свойствами Интернета и практикой развёртывания протоколов за пределами первоначально предполагаемых защищённых сред. Выбор конкретных сервисов безопасности зависит от приложения и модели угроз: конфиденциальность требуется не всег…
Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)
The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on.
Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)
This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status.
This document describes the registration of the MIME sub-type image/t38. The encoding is defined by [T.38] and is intended for use as an SDP media descriptor.
This document defines a DHCP-for-IPv4 option that contains a list of domain names or IPv4 addresses that can be mapped to one or more SIP outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server.
RFC 3360 рассматривает практику, при которой межсетевые экраны, балансировщики нагрузки или веб-серверы отвечают TCP Reset на TCP SYN-пакеты с установленными флагами зарезервированного поля заголовка TCP, в частности при согласовании ECN. Документ утверждает, что такой ответ не соответствует стандартам TCP и размывает семантику TCP Reset. Он отмечает, что сброс либо отбрасывание таких пакетов преп…
Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System
This draft describes implementation codepoints within IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft summarizes all TLV codepoints that are being used by the protocol and its pending extensions.
Optional Checksums in Intermediate System to Intermediate System (ISIS)
This draft describes an optional extension to IS-IS protocol, used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. IS-IS originally does not provide CSNP and PSNP checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protoco…
The Internet exhibits certain specific types of behavior (e.g., bursty packet loss) that can affect the performance seen by the users as well as the operators. The loss pattern or loss distribution is a key parameter that determines the performance observed by the users for certain real-time applications such as packet voice and video. For the same loss rate, two different loss distributions could…
Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines
This document provides guidance to aid in the understanding of collaboration on standards development between the International Telecommunication Union -- Telecommunication Standardization Sector (ITU-T) and the Internet Society (ISOC) / Internet Engineering Task Force (IETF). It is an update of and obsoletes [RFC 2436]. The updates reflect changes in the IETF and ITU-T since RFC 2436 was written.…
Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)
The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard method for transporting the link layer of PPP [RFC1661] between a dial-up server and a Network Access Server, using a network connection in lieu of a physical point to point connection. This document describes the use of an ATM network for the underlying network connection. ATM User-Network Interface (UNI) Signalling Specificati…
Internet Open Trading Protocol Version 2 Requirements
Version 2 of the Internet Open Trading Protocol (IOTP) will extend the interoperable framework for Internet commerce capabilities of Version 1 while replacing the XML messaging and digital signature part of IOTP v1 with standards based mechanisms. Additional features are listed and divided into those the will, may, and will not be included.
Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment
This document offers a framework for IP multicast deployment in an MPLS environment. Issues arising when MPLS techniques are applied to IP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) te…
Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status
The Connection-less Lightweight Directory Access Protocol (CLDAP) technical specification, RFC 1798, was published in 1995 as a Proposed Standard. This document discusses the reasons why the CLDAP technical specification has not been furthered on the Standard Track. This document recommends that RFC 1798 be moved to Historic status.
User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals
This document aims to present a set of SIP user requirements that support communications for deaf, hard of hearing and speech-impaired individuals. These user requirements address the current difficulties of deaf, hard of hearing and speech-impaired individuals in using communications facilities, while acknowledging the multi-functional potential of SIP-based communications. A number of issues rel…
A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force
RFC 3349 устанавливает практику назначения временных URI для BEEP-профилей, разрабатываемых рабочими группами IETF. Председатель рабочей группы назначает идентификатор вида "http://iana.org/beep/transient/XXX/YYY", где XXX — мнемоника рабочей группы, а YYY — уникальная в остальном произвольная строка; результирующий URI должен соответствовать синтаксису URI, а YYY может содержать подиерархию. Зате…