| |
|
| |
| | Advice for Safe Handling of Malformed Messages |
| |
|
Although Internet mail formats have been precisely defined since the 1970s, authoring and handling software often show only mild conformance to the specifications. The distributed and non- interactive nature of email has often prompted adjustments to receiving software, to handle these variations, rather than trying to gain better conformance by senders, since the receiving operator is primarily driven by complaining recipient users and has no authority over the sending side of the system. Processing with such flexibility comes at some cost, since mail software is faced with decisions about whether or not to permit non-conforming messages to continue toward their destinations unaltered, adjust them to conform (possibly at the cost of losing some of the original message), or outright rejecting them. A core requirement for interoperability is that both sides of an exchange work from the same details and semantics. By having receivers be flexible, beyond the specifications, there can be -- and often has been -- a good chance that a message will not be fully interoperable. Worse, a well-established pattern of tolerance for variations can sometimes be used as an attack vector. This document includes a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. It must be emphasized, however, that the intent of this document is not to standardize malformations or otherwise encourage their proliferation. The messages are manifestly malformed, and the code and culture that generates them needs to be fixed. Therefore, these messages should be rejected outright if at all possible. Nevertheless, many malformed messages from otherwise legitimate senders are in circulation and will be for some time, and, unfortunately, commercial reality shows that we cannot always simply reject or discard them. Accordingly, this document presents alternatives for dealing with them in ways that seem to do the least additional harm until the infrastructure is tightened up to match the standards. |
| | A Media Type for XML Patch Operations |
| |
|
The XML Patch media type "application/xml-patch+xml" defines an XML document structure for expressing a sequence of patch operations that are applied to an XML document. The XML Patch document format's foundations are defined in RFC 5261, this specification defines a document format and a media type registration, so that XML Patch documents can be labeled with a media type, for example in HTTP conversations. In addition to the media type registration, this specification also updates RFC 5261 in some aspects, limiting these updates to cases where RFC 5261 needed to be fixed, or was hard to understand. |
| | Framework for GMPLS and PCE Control of G.709 Optical Transport Networks |
| |
|
This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as published in 2012. |
| | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control |
| |
|
ITU-T Recommendation G.709 [G709-2012] has introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. This document provides an alternative to RFC4328 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the full set of OTN features including ODU0, ODU4, ODU2e and ODUflex. |
| | IODEF-extension for structured cybersecurity information |
| |
| | draft-ietf-mile-sci-07.txt |
| | Date: |
18/06/2013 |
| | Authors: |
Takeshi Takahashi, Kent Landfield, Tom Millar, Youki Kadobayashi |
| | Working Group: |
Managed Incident Lightweight Exchange (mile) |
| | Formats: |
pdf txt |
|
This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity information among cybersecurity entities and facilitate their operations. It provides the capability of embedding structured information, such as identifier- and XML-based information. |
| | MPLS-TP Operations,Administration,and Management (OAM) Identifiers Management Information Base (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 Operations, Administration, and Management (OAM) identifiers related managed objects for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). |
| | Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 |
| |
|
A base solution to support IP multicasting in a PMIPv6 domain is specified in [RFC6224]. In this document, some enhancements to the base solution are described. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the MAG can provide access to multicast content in the local network. These enhancements provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios. |
| | Prefix Delegation Support for Proxy Mobile IPv6 |
| |
| | draft-ietf-netext-pd-pmip-09.txt |
| | Date: |
18/06/2013 |
| | Authors: |
Xingyue Zhou, Jouni Korhonen, Carl Williams, Sri Gundavelli, Carlos Bernardos |
| | Working Group: |
Network-Based Mobility Extensions (netext) |
| | Formats: |
txt |
|
This specification defines extensions to Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain delegated IP prefixes for its attached mobile networks. The mobility entities in the network will provide network-based mobility management support for those delegated IP prefixes just as how IP mobility support is provided for the mobile node's home address. Even as the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. |
| | dIVI: Dual-Stateless IPv4/IPv6 Translation |
| |
| | draft-xli-behave-divi-05.txt |
| | Date: |
18/06/2013 |
| | Authors: |
Congxiao Bao, Xing Li, Yu Zhai, Wentao Shang |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document presents the concepts and the implementations of address-sharing dual-stateless IPv4/IPv6 translation (dIVI). The dIVI is an extension of 1:1 stateless IPv4/IPv6 translation with features of IPv4 address sharing and dual translation. The major benefits of those extensions are using public IPv4 addresses more effectively and removing the requirements of DNS64 and ALG, without loosing the stateless, end-to-end address transparency and bidirectional-initiated communications. |
| | eXtensible Access Control Markup Language (XACML) XML Media Type |
| |
|
This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML). Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. Online access to all versions and files is available on github [2]. |
| | ICN Baseline Scenarios and Evaluation Methodology |
| |
| | draft-pentikousis-icn-scenarios-03.txt |
| | Date: |
18/06/2013 |
| | Authors: |
Kostas Pentikousis, Borje Ohlman, Daniel Corujo, Gennaro Boggia, Gareth Tyson, Elwyn Davies, Dorothy Gellert, Priya Mahadevan, Spiros Spirou, Antonella Molinaro |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document aims at establishing a common understanding about potential experimental setups where different information-centric networking (ICN) approaches can be tested and compared against each other while showcasing their advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. The scenarios presented aim to exercise a variety of aspects that an ICN solution can address. On the one hand, we consider general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficacy, energy consumption frugality, and disruption and delay tolerance. On the other hand, we focus on ICN- specific aspects, such as information security and trust, persistence, availability, provenance, and location independence. |
| | Backup Path for Point-to-Point Routes in Low Power and Lossy Networks |
| |
|
In this draft, a backup path setup mechanism is proposed for the P2P-RPL protocol in Low Power and Lossy Networks (LLNs). This mechanism allows sensor nodes to send packets over the backup path without rediscovering the p2p path in case of path failure, thus improving the reliability of p2p transmission. |
| | Flow-state dependent packet selection techniques |
| |
|
The demands on the networking infrastructure and thus the switch/router bandwidths are growing exponentially; the drivers are bandwidth hungry rich media applications, inter data center communications etc. Using sampling techniques, for a given sampling rate, the amount of samples that need to be processed is increasing exponentially especially for applications like security threat detection. This draft elaborates on flow-state dependent packet selection techniques and the relevant information models. It describes how these techniques can be effectively used to reduce the number of samples for applications like security threat detection. |
| | Registration Data Access Protocol Basic Search Processing |
| |
|
This document describes path segments and query parameters needed to construct HTTP URLs that may be used to search for and retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. It also describes a method of encoding responses using Javascript Object Notation (JSON). |
| | Transmission of IPv6 packets over ITU-T G.9959 Networks |
| |
|
This document describes the frame format for transmission of IPv6 packets and a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks. |
| | IANA Guidance for Managing the ULE Registry |
| |
|
This document proposes an update to RFC 4326 to clarify and update the allocation rules for the Unidirectional Lightweight Encapsulation (ULE) next header registry. This registry is used by ULE and Generic Stream Encapsulation (GSE) to record the codepoints of extension headers and protocols supported by these encapsulation protocols. |
| | A Group Text Chat Purpose for Conference and Service URIs in the Session Initiation Protocol (SIP) Event Package for Conference State |
| |
|
This document defines and registers a value of "grouptextchat" ("Group Text Chat") value for the URI element of SIP's Conference Event Package [RFC4575]. |
| | Router Advertisement based privacy extension in IPv6 autoconfiguration |
| |
|
Privacy is an important issue which concerns many governments and users, with its importance becoming more evident every day. Nodes change their IP addresses frequently in order to avoid being tracked by attackers. The act of frequently changing IP addresses also helps to prevent the leakage of information by nodes. In IPv6 networks there is currently one solution for maintaining the privacy of nodes when IPv6 StateLess Address AutoConfiguration (SLAAC) (RFC 4862) is used. Unfortunately there are some problems associated with this solution which entails the use of the Privacy Extension (RFC 4941). One of the issues with this RFC concerns the wording that is used which allows the implementation to make the choice as to what approach to use and in so doing, in some cases, the choice made is not the most prudent or best approach and this is not ideal and can cause some problems. Some of these problems are concerned with not generating a new Interface ID (IID) after changing the router prefix. Another concern would be the fact that nodes may use an IID that was generated based on a MAC address as a public address, and then use this in their response. The act of cutting the current connections to other nodes, if the max lifetime of the old IID has elapsed, is also not clearly explained nor is whether or not the already used IID should be kept in stable storage, There is also a concern about the need to have stable storage available for the generation of a randomized IID. The RFC gives no explanation as to how to make use of CGA in its randomizing solution when stable storage is not available or how to use the same approach for random value generation in all implementations where there is a lack of stable storage. The purpose of this document is to address these issues, to update the current RFC and to introduce a new algorithm for the lifetime of IID. |
| | Interface Selection Mechanism for Multiple Interfaces IPv6 Hosts |
| |
|
This document describes an interface selection mechanism that enables multiple interfaces (multihomed) IPv6 hosts to select their most appropriate egress interface to send data over the network. The mechanism extends the Neighbor Discovery (ND) protocol [RFC4861] with two new Router Advertisement options. |
| | Port Control Protocol (PCP) Proxy Function |
| |
|
This document specifies a new PCP functional element denoted as PCP Proxy. The PCP Proxy relays PCP requests received from PCP Clients to upstream PCP Server(s). This function is mandatory when PCP Clients can not be configured with the address of the PCP Server located more than one hop. |
| | TRILL: Adjacency |
| |
| | draft-ietf-trill-rfc6327bis-00.txt |
| | Date: |
18/06/2013 |
| | Authors: |
Donald Eastlake, Radia Perlman, Anoop Ghanwani, Vishwas Manral |
| | Working Group: |
Transparent Interconnection of Lots of Links (trill) |
| | Formats: |
txt |
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol supports arbitrary link technologies between TRILL switches including point-to-point links and multi-access LAN (Local Area Network) links that can have multiple TRILL switches and end stations attached. TRILL uses IS-IS (Intermediate System to Intermediate System) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacency between TRILL switches, also known as RBridges. It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bi- Directional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325. |
| | Public Key Pinning Extension for HTTP |
| |
|
This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. |
| | HTTP usage in the Registration Data Access Protocol (RDAP) |
| |
|
This document is one of a collection that together describe the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). |
| | RTP Control Protocol (RTCP) Extended Report (XR) Blocks for QoE Metric Reporting |
| |
|
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block including two new segment types and associated SDP parameters that allow the reporting of QoE metrics for use in a range of RTP applications. |
| |
|
| |
| | The 'acct' URI Scheme |
| |
|
This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account. |
| | BFD Management Information Base |
| |
|
This draft 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 modeling Bidirectional Forwarding Detection (BFD) protocol. |
| | Distributed Mobility Management: Current practices and gap analysis |
| |
|
The present document analyses deplyment practices of existing mobility protocols in a distributed mobility management environment. It also identifies some limitations compared to the expected functionality of a fully distributed mobility management system. The comparison is made taking into account the identified DMM requirements. |
| | IS-IS Traffic Engineering (TE) Metric Extensions |
| |
|
In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to IS-IS TE [RFC5305] such that network performance information can be distributed and collected in a scalable fashion. The information distributed using ISIS TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. |
| | LISP MIB |
| |
| | draft-ietf-lisp-mib-11.txt |
| | Date: |
17/06/2013 |
| | Authors: |
Gregg Schudel, Amit Jain, Victor Moreno |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
| | Formats: |
txt |
|
This document defines the MIB module that contains managed objects to support the monitoring devices that support the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics. |
| | Security Threats for NHDP |
| |
|
This document analyzes common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. This document is not intended to propose solutions to the threats described. |
| | Offer/Answer Considerations for G723 Annex A and G729 Annex B |
| |
|
RFC4856 describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the Session Description protocol(SDP) offer and answer. This document provides the offer/ answer considerations for these parameters and updates RFC4856. |
| | Update Notifications for Proxy Mobile IPv6 |
| |
|
This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. |
| | YANG Data Model for System Management |
| |
|
This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a NETCONF server. This includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. |
| | Definition of Managed Objects for SAVI Protocol |
| |
| | draft-an-savi-mib-05.txt |
| | Date: |
17/06/2013 |
| | Authors: |
Changqing An, Jiahai Yang, Jianping Wu, Jun Bi |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
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 objects for managing SAVI (Source Address Validation Improvements) protocol instance. |
| | A Description of KCipher-2 Encryption Algorithm |
| |
|
This document describes the KCipher-2 encryption algorithm. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. No security vulnerability has been found as of the time this document was written. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan. |
| | Miscellaneous CoAP Group Communication Topics |
| |
|
This document contains miscellaneous text around the topic of group communication for the Constrained Application Protocol (CoAP). The first part contains, for reference, text that was removed from the WG version of Group Communication for CoAP draft. The second part describes group communication and multicast functionality that may be input to future standardization in the CoRE WG. |
| | Indication of support for reverse keep-alive |
| |
|
This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "rkeep". The "rkeep" parameter allows a SIP entity to indicate willingness to receive keep-alives from its adjacent downstream SIP entity, the adjacent downstream SIP entity to indicate willingness to send keep-alives, and for SIP entities willing to send keep-alives to inform the receiver about the keep- alive interval. |
| | Automating DNSSEC delegation trust maintenance |
| |
|
This document describes a method to allow DNS operators to more easily update DNSSEC Key Signing Keys using DNS as communication channel. This document does not address the initial configuration of trust anchors for a domain. |
| | Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types |
| |
|
This document defines the syntax for two Cryptographic Message Syntax (CMS) content types, one for key package receipts, and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types. |
| | DKIM is Harmful as Specified |
| |
|
Currently, email lacks conventions ensuring SMTP clients can be identified by an authenticated domain. Unfortunately many hope to use DKIM as an alternative, but it is independent of intended recipients and domains accountable for having sent the message. This means DKIM is poorly suited at establishing abuse assessments of unsolicited commercial email otherwise known as SPAM, nor was this initially DKIM's intent. DKIM lacks message context essential to ensure fair assessment and to ensure this assessment is not poisoned (Who initiated the transaction and to whom). DKIM was instead intended to establish increased levels of trust based upon valid DKIM signatures controlling acceptance and what a user sees within the FROM header field. But DKIM failed to guard against pre-pended header fields where any acceptance based on valid DKIM signatures is sure to exclude header field spoofing, especially that of the FROM. This weakness allows malefactors to exploit DKIM signature acceptance established by high-volume DKIM domains to spoof ANY other domain, even when prohibited within the Signer's network. |
| | The application/cms media type |
| |
|
This document registers the application/cms media types for use with the corresponding CMS (Cryptographic Message Syntax) content types. |
| | No Plan: Economical Use of the Offer/Answer Model in WebRTC Sessions with Multiple Media Sources |
| |
|
This document describes a model for the lightweight use of SDP Offer/ Answer in WebRTC. The goal is to minimize reliance on Offer/Answer exchanges in a WebRTC session and provide applications with the tools necessary to implement the signalling that they may need in a way that best fits their custom requirements and topologies. This simplifies signalling of multiple media sources or providing RTP Synchronisation source (SSRC) identification in multi-party sessions. Another important goal of this model is to remove from clients topological constraints such as the requirement to know in advance all SSRC identifiers that they could potentially introduce in a particular session. The model described here is similar to the one employed by the data channel JavaScript APIs in WebRTC, where methods are supported on PeerConnection without being reflected in SDP. This document does not question the use of SDP and the Offer/Answer model or the value they have in terms of interoperability with legacy or other non-WebRTC devices. |
| | Extensible Provisioning Protocol (EPP) Trademark Mapping |
| |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of trademark stored in a trademark clearinghouse. Specified in XML, the mapping defines EPP command syntax and semantics as applied to trademark. |
| | Differentiated Network-Located Function Chaining Framework |
| |
|
IP networks rely more and more on the combination of advanced functions (besides the basic routing and forwarding functions). This document defines a solution to enforce Network-Located Function Chaining (NLFC) with minimum requirements on the underlying network. The proposed solution allows for Differentiated Forwarding (DiffForward): packets are classified at the entry point of an NLFC- enabled network, and are then forwarded on a per NLFC map basis. |
| | A Trust Model for ABFAB Trust Routers |
| |
|
Trust routers form an integral part of the ABFAB infrastructure for determining routes between IdPs and RPs and determining CoI membership. Since it is inherent in their name that they are to be trusted, this Internet Draft specifies a trust model for their operation, so that IdPs and RPs can rely on them to perform the tasks that they are trusted to perform. These tasks are: - form a trusted route between an IdP and RP - ensure that a community of interest (CoI)only has the members that it should have |
| | Multi-homed network in EVPN |
| |
|
To enhance the reliability, bridged network is normally multi-homed to an EVPN network, there are two categories of mechanisms to avoid the layer 2 traffic loop. The first category does not require the PEs participating in the control protocol of the bridged network, while the second category requires that. [EVPN] described one of the first category mechanisms called designated forwarder (DF) election to achieve loop avoidance and vlan-based load balancing. This draft mainly focuses on the second category of mechanisms which can achieve intra-vlan MAC-based load balancing. MAC-based VLAN balancing is more applicable than DF election mechanism if all end stations in bridged network are on the same VLAN which can cause traffic congestion in DF link. |
| | CoAP Entities |
| |
|
This document describes a format to create entities that can be used for group communication using CoAP unicast messages. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. |
| | Packet Sequence Number based directional ETT Metric for OLSRv2 |
| |
|
This document specifies an Estimated Travel Time (ETT) link metric for usage in OLSRv2. |
| | RTP Control Protocol (RTCP) Extended Report (XR) Block for Jitter Buffer Metric Reporting |
| |
|
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of Jitter Buffer metrics for a range of RTP applications. |
| | RTCP XR Report Block for Concealment metrics Reporting on Audio Applications |
| |
|
This document defines two RTCP XR Report Blocks that allows the reporting of concealment metrics for audio applications of RTP. |
| |
|
| |
| | DS-Lite Failure Detection and Failover |
| |
|
In DS-Lite, the tunnel is stateless, not associated with any state information, and the CGN function at the AFTR is stateful. Currently, there is no failure detection and failover mechanism for both stateless tunnel and stateful CGN function, which makes it difficult to manage and diagnose if there is a problem. This draft analyzes the applicability of some of the possible solutions. |
| | Asymmetric OSPF Hold Timer |
| |
|
Current OSPF standard requires that the HELLO/Dead interval be symmetric on either side of the link in order to maintain adjacency. There are many scenarios in which this may not be desirable. This memo describes a technique to allow OSPF adjacency to be maintained with asymmetric values of the OSPF Dead interval. |
| | IS-IS Flooding Scope LSPs |
| |
|
Intermediate System To Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers. However the current flooding scopes are limited to either area wide scope or domain wide scope. There are existing use cases where support of other flooding scopes are desirable. This document defines new Protocol Data Units (PDUs) which provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care. |
| | The IETF Profile URI Registry |
| |
|
This document defines a registry for profile URIs to be used in specifications standardizing profiles. |
| | Concise Binary Object Representation (CBOR) |
| |
|
The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. |
| | A questionable method for mitigating namespace collisions |
| |
|
This document outlines a method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict. |
| | OAuth 2.0 Token Revocation |
| |
|
This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to cleanup security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. |
| |
|
| |
| | GMPLS RSVP-TE extensions for OAM Configuration |
| |
|
OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling. |
| | GMPLS RSVP-TE Extensions for Ethernet OAM Configuration |
| |
|
The GMPLS controlled Ethernet Label Switching (GELS) work extended GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs, and defines the Ethernet technology specific TLVs based on [OAM-CONF-FWK]. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms. |
| | A Media-based Traceroute Function for the Session Initiation Protocol (SIP) |
| |
|
SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field, in order to determine the reachability path of requests to a target. A mechanism for media-loopback calls has also been defined separately, which enables test calls to be generated which result in media being looped back to the originator. This document describes a means of performing hop-by-hop traceroute-style test calls using the media- loopback mechanism, in order to test the media path when SIP sessions go through media-relaying B2BUAs. |
| | PCP Stability of External Address Recommendations |
| |
|
This document recommends PCP Server and client behavior in light of Address Pooling Paired. |
| | Composite Link Framework in Multi Protocol Label Switching (MPLS) |
| |
|
This document specifies a framework for support of composite link in MPLS networks. A composite link consists of a group of homogenous or non-homogenous links that have the same forward adjacency and can be considered as a single TE link or an IP link in routing. A composite link relies on its component links to carry the traffic over the composite link. Applicability is described for a single pair of MPLS-capable nodes, a sequence of MPLS-capable nodes, or a set of layer networks connecting MPLS-capable nodes. |
| | Composite Link Use Cases and Design Considerations |
| |
|
This document provides a set of use cases and design considerations for composite links. Composite link is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques. |
| |
|
| |
| | Inter-destination Media Synchronization using the RTP Control Protocol (RTCP) |
| |
| | draft-ietf-avtcore-idms-11.txt |
| | Date: |
14/06/2013 |
| | Authors: |
Ray van Brandenburg, Hans Stokking, Oskar van Deventer, Fernando Boronat, Mario Montagud, Kevin Gross |
| | Working Group: |
Audio/Video Transport Core Maintenance (avtcore) |
| | Formats: |
txt |
|
This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is useful are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. |
| | Native NAT Traversal Mode for the Host Identity Protocol |
| |
|
This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. |
| | Virtual Private Lan Services (VPLS) Management Information Base |
| |
|
This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Virtual Private LAN services. It needs to be used in conjunction with Pseudowire (PW) Management Information Base [RFC5601]. |
| | Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers |
| |
|
This specification defines a new SDP Grouping Framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=" lines). |
| | Via header field parameter to indicate received realm |
| |
|
This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "received-realm", which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received, using a network realm value associated with the adjacent network. |
| | Delay Limits and Multiplexing Policies to be employed with Tunneling Compressed Multiplexed Traffic Flows |
| |
|
This document contains recommendations to be taken into account when using methods which optimize bandwidth utilization through compression, multiplexing, and tunneling traffic flows (TCMTF) over a network path. Different multiplexing policies and implementation issues which are service and link specific are discussed. Additionally, this document describes policies which can be used for detecting, classifying, and choosing the network flows suitable for optimization by using TCMTF. Finally, recommendations of maximum tolerable delays to be added by optimization techniques are reported. Recommendations are presented only for network services for which such bandwidth optimization techniques are applicable (i.e., services with low payload to header size ratio, which will also be denoted as "small-packet flows"). |
| | A ROA Status Attribute for RPSL Objects |
| |
|
This document describes an attribute for Routing Policy Specification Language (RPSL) route and route6 objects that documents the presence and validity of a Route Origin Authorization (ROA) for the given prefix and origin values contained within the object. It allows parties who employ Internet Routing Registries (IRR's) for routing policy configuration generation to easily ascertain whether a given object has a ROA covering the object. The primary objective is to enable existing IRR tools to make use of the ROA information with minimal modifications. |
| | Coupled congestion control for RTP media |
| |
|
When multiple congestion controlled RTP sessions traverse the same network bottleneck, it can be beneficial to combine their controls such that the total on-the-wire behavior is improved. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. |
| | P6R's Secure Shell Public Key Subsystem |
| |
|
The Secure Shell Public Key Subsystem protocol defines a key distribution protocol to provision an SSH server with user's public keys. However, that protocol is limited to provisioning an SSH server. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport. |
| | Update to the PCP specification |
| |
|
The Port Control Protocol allows clients to request mappings in NAT gateways and firewalls. This document specifies the PCP UNSUPP_FAMILY error code, which enables PCP servers to inform clients when the requested external address family is not supported. This document also removes the requirement for the PCP server to validate the mapping nonce, which proved to be unhelpful in practice. |
| | CLUE Switching Mixer Example |
| |
|
This document presents an example multipoint use case scenario for CLUE. This example uses the media switching variety of the Topo- Mixer RTP topology. This example is intended to promote discussion about how to implement it using the CLUE Framework, and whether or not the framework as currently defined is sufficient to enable this use case. This first version is incomplete, and is intended to raise questions and prompt discussion. |
| | Transporting Timing messages over MPLS Networks |
| |
| | draft-ietf-tictoc-1588overmpls-05.txt |
| | Date: |
14/06/2013 |
| | Authors: |
Shahram Davari, Amit Oren, Manav Bhatia, Peter Roberts, Laurent Montini |
| | Working Group: |
Timing over IP Connection and Transfer of Clock (tictoc) |
| | Formats: |
txt xml |
|
This document defines the method for transporting Timing messages such as PTP and NTP over an MPLS network. The method allows for the easy identification of these PDUs at the port level to allow for port level processing of these PDUs in both LERs and LSRs. The basic idea is to transport Timing messages inside dedicated MPLS LSPs. These LSPs only carry Timing messages and possibly Control and Management packets, but they do not carry customer traffic. Two methods for transporting Timing messages over MPLS are defined. The first method is to transport Timing messages directly over the dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for MPLS networks. The second method is to transport Timing messages inside a PW via Ethernet encapsulation. |
| |
|
| |
| | Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces |
| |
| | draft-ietf-bfd-on-lags-01.txt |
| | Date: |
13/06/2013 |
| | Authors: |
Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, Jeffrey Haas |
| | Working Group: |
Bidirectional Forwarding Detection (bfd) |
| | Formats: |
txt |
|
This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, LACP. It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. This mechanism utilizes a well-known UDP port distinct from that of single-hop BFD over IP. This new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. |
| | Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information |
| |
|
This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. |
| | Extensions to VPLS PE model for Provider Backbone Bridging |
| |
|
IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. Virtual Private LAN Service (VPLS) [RFC4664] provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running RSTP or MSTP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. |
| | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat |
| |
|
This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). |
| | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions |
| |
|
As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. |
| | Network Virtualization Overlay Control Protocol Requirements |
| |
| | draft-kreeger-nvo3-overlay-cp-04.txt |
| | Date: |
13/06/2013 |
| | Authors: |
Lawrence Kreeger, Dinesh Dutt, Thomas Narten, David Black, Murari Sridharan |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The document "Problem Statement: Overlays for Network Virtualization" discusses the needs for network virtualization using overlay networks in highly virtualized data centers. The problem statement outlines a need for control protocols to facilitate running these overlay networks. This document outlines the high level requirements to be fulfilled by the control protocols related to building and managing the mapping tables and other state information used by the Network Virtualization Edge to transmit encapsulated packets across the underlying network. |
| | End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) |
| |
|
This document defines two methods for securing objects (often referred to as stanzas) for the Extensible Messaging and Presence Protocol (XMPP), which allows for efficient asynchronous communication between two entities, each with might have multiple devices operating simultaneously. One is a method to encrypt stanzas to provide confidentiality protection; another is a method to sign stanzas to provide authentication and integrity protection. This document also defines a related protocol for entities to request the ephemeral session keys in use. |
| | OmniBroker Protocol |
| |
|
An Omnibroker is an agent chosen and trusted by an Internet user to provide information such as name and certificate status information that are in general trusted even if they are not trustworthy. Rather than acting as a mere conduit for information provided by existing services, an Omnibroker is responsible for curating those sources to protect the user. The Omnibroker Protocol (OBP) provides an aggregated interface to trusted Internet services including DNS, OCSP and various forms of authentication service. Multiple transport bindings are supported to permit efficient access in virtually every common deployment scenario and ensure access in any deployment scenario in which access is not being purposely denied. |
| | Emergency Services Support in WebRTC |
| |
|
The Web Real-Time Communication (WebRTC) framework supports interactive communication between web-browsers, including support for audio, video and text. This document describes how emergency services functionality can be implemented within the WebRTC framework, including support for location and call routing as well as interoperability with Public Safety Answering Points (PSAPs) supporting next generation emergency services. |
| | Requirements for Marking SIP Messages to be Logged |
| |
|
SIP networks use signalling monitoring tools to diagnose user reported problem and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signalling will take between clients, and therefore impractical to monitor SIP signalling end-to-end. This draft describes requirements for adding an indicator to the SIP protocol which can be used to mark signalling as of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. |
| | CLUE Signaling |
| |
|
This document specifies how signaling is conducted in the course of CLUE sessions. This includes how SIP/SDP signaling is applied to CLUE sessions as well as defining a CLUE-specific signaling protocol that complements SIP/SDP and supports negotiation of CLUE application level data. |
| | Using JavaScript Object Notation (JSON) Web Encryption (JWE) for Protecting JSON Web Key (JWK) Objects |
| |
|
This document specifies an approach to protecting a private key formatted as a JavaScript Syntax Object Notation (JSON) Web Key (JWK) object using JSON Web Encryption (JWE). This document also specifies a set of algorithms for protecting such content using password-based cryptography. |
| | IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters |
| |
|
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 5342. |
| | JSON Service Connect (JCX) Protocol |
| |
|
JSON Service Connect (JCX) is a JSON/REST Web Service that may be used to establish and maintain a 'connection binding' of a device to an account held with a Web Service Provider. Multiple connection bindings may be established under the same account to support multiple devices and/or multiple users of a single device. A connection binding permits a device to securely connect to one or more services offered by the Web Service Provider with support for protocol and protocol version agilty and fault tollerance. The protocol is presented as a HTTP/JSON Web Service and uses the HTTP session continuation mechanism for authentication of transaction messages and supports negotiation of a HTTP session continuation mechanism context for the established endpoint connections. |
| | Carrying Metadata in IP Networks |
| |
| | draft-bryant-ip-metadata-00.txt |
| | Date: |
13/06/2013 |
| | Authors: |
Stewart Bryant, Jim Guichard, Carlos Pignataro, Simon Spraggs |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document defines the mechanism for carrying and identifying the presence of metadata carried in addition to the payload in IPv4 and IPv6 packets. |
| | Common Metadata Header Format for IP/MPLS Networks |
| |
|
This document defines the common format for the metadata header used to carry metadata in IPv4, IPv6, and MPLS packets. |
| | Carrying Metadata in MPLS Networks |
| |
|
This document defines the mechanism for identifying the presence of metadata carried in addition to the payload in MPLS packets. |
| | Key Wrapping with AES GCM for JWE |
| |
|
This specification defines how to encrypt (wrap) keys with the AES GCM algorithm for JSON Web Encryption (JWE) objects. |
| | Network Service Chaining Problem Statement |
| |
|
This document provides an overview of the issues associated with the deployment of network services (such as firewalls, load balancers) in large-scale environments. The term service chaining is used to describe the deployment of such services, and the ability of a network operator to specify an ordered list of services that should be applied to a deterministic set of traffic flows. Such service chains require integration of service policy alongside the deployment of applications, while maintaining optimal use of available network capacity and resources. |
| | Network Service Header |
| |
| | draft-quinn-nsh-00.txt |
| | Date: |
13/06/2013 |
| | Authors: |
Paul Quinn, Rex Fernando, Jim Guichard, Surendra, Abhishek Chauhan, Michael Smith, Navindra Yadav, Brad McConnell |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft describes a Network Service Header (NSH) that can be added to encapsulated network packets or frames to create network service paths. In addition to path information, this header also carries metadata used by network devices and/or network services. |
| | NVGRE-EXT: Network Virtualization using Generic Routing Encapsulation Extensions |
| |
|
This document describes the usage of "Network Virtualization using Generic Routing Encapsulation (NVGRE)" Extensions (NVGRE-EXT). The focus of this document is on specifying the control plane operations done using NVGRE packets. |
| | The Port Control Protocol in Dual-Stack Lite environments |
| |
| | draft-ietf-pcp-dslite-00.txt |
| | Date: |
13/06/2013 |
| | Authors: |
Francis Dupont, Tina Tsou, Jacni Qin, Margaret Wasserman, Dacheng Zhang |
| | Working Group: |
Port Control Protocol (pcp) |
| | Formats: |
xml txt |
|
This document specifies the so-called "plain mode" for the use of the Port Control Protocol (PCP) in Dual-Stack Lite (DS-Lite) environments. |
| |
|
| |
| | A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) |
| |
|
This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique- local addresses. |
| | Message Header Field for Indicating Message Authentication Status |
| |
|
This document specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. This document is a candidate for Internet Standard status. [RFC Editor: Please delete this notation, as I imagine it will be indicated some other way.] |
| | Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks |
| |
|
This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains. |
| | Definition of Managed Objects for the Optimized Link State Routing Protocol version 2 |
| |
|
This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into configuration information, state information, performance information, and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues of the routing protocol. Two levels of compliance allow this MIB module to be deployed on constrained routers. |
| | The Subnetwork Encapsulation and Adaptation Layer (SEAL) |
| |
|
This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL). SEAL operates over virtual topologies configured over connected IP network routing regions bounded by encapsulating border nodes. These virtual topologies are manifested by tunnels that may span multiple IP and/or sub-IP layer forwarding hops, where they may incur packet duplication, packet reordering, source address spoofing and traversal of links with diverse Maximum Transmission Units (MTUs). SEAL addresses these issues through the encapsulation and messaging mechanisms specified in this document. |
| | AS2 Restart for Very Large Messages |
| |
|
AS2 Restart provides a method for AS2 clients and servers to restart payload transfers from the point of failure without requiring the entire document to be resent. Keywords |
| | Requirements for Message Access Control |
| |
|
There are many situations where organizations want to protect information with robust access control, either for implementation of intellectual property right protections, enforcement of contractual confidentiality agreements or because of legal regulations. The Enhanced Security Services (ESS) for S/MIME defines an access control mechanism for email which is enforced by the recipient's client after decryption of the message. The ESS mechanism therefore is dependent on the correct access policy configuration of every recipient's client. This mechanism also provides full access to the data to all recipients prior to the access control check, this is considered to be inadequate due to the difficulty in demonstrating policy compliance. This document lays out the deficiencies of the current ESS security label, and presents requirements for a new model for providing access control to messages where the access check is performed prior to message content decryption. This new model also does not require policy configuration on the client to simplify deployment and compliance verification. The proposed model additionally provides a method where non-X.509 certificate credentials can be used for encryption/decryption of S/MIME messages. |
| | Intellectual Property Rights in IETF Technology |
| |
|
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and obsoletes RFC 3979 and RFC 4879. |
| | Multicast UDP Usage Guidelines for Application Designers |
| |
|
The multi-recipient nature of Multicast prevents the use of any pont- to-point connection-oriented transport, therefore restricts all Multicast data to be sent over the User Datagram Protocol (UDP). UDP provides a minimal message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use Multicast UDP as an Internet service must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of multicast applications and higher-level protocols. |
| | Resource Records for EUI-48 and EUI-64 Addresses in the DNS |
| |
|
48-bit Extended Unique Identifiers (EUI-48) and 64-bit Extended Unique Identifiers (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g. Ethernet. This document describes two new DNS resource record types, EUI48 and EUI64, for encoding Ethernet addresses in the DNS. This document describes potentially severe privacy implications resulting from indiscriminate publication of link-layer addresses in the DNS. This document recommends that EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated. |
| | Problems with STUN Authentication for TURN |
| |
|
This document discusses some of the issues with STUN authentication for TURN messages. |
| | Profiling of DTLS for CoAP-based IoT Applications |
| |
|
This document collects various implementation challenges of DTLS on embedded systems, and proposes a profile of DTLS for CoAP-based Internet of Things (IoT) applications. Specifically, this document investigates the application features and functionality of DTLS protocol, the fragmentation issue of DTLS Handshake protocol, and the complexity of the DTLS Handshake state machine. A RESTful DTLS Handshake which relies on CoAP Block-wise Transfer is proposed to address the fragmentation issue. The next step is to define a DTLS profile for embedded systems. |
| | Offer & Answer interworking between JSEP & SIP |
| |
|
Real time communcation Web (RTCWeb) workgroup defines the real time commmunication using JavaScript Session establishment protocol (JSEP) as an offer/answer mechanism. Session Initiation protocol (SIP) is IETF defined and well deployed protocol for real time communication. This document provides offer & answer interworking between JSEP and SIP. |
| | Middlebox considerations in NVO3 overlay networks |
| |
|
This document examines middlebox considerations in nvo3 overlay networks. We are concerned with both the impacts of middlebox presence on nvo3 overlays, and the impacts of nvo3 overlays and encapsulations on middlebox function. |
| | DHCPv4 over A+P softwires |
| |
|
A node getting IPv4 access via an A+P mechanism might need other IPv4 configuration information. This memo describes how DHCPv4 is supported, on IPv4 over IPv6 tunnels with shared IPv4 addresses. |
| | vCard S/MIME Capabilities Property |
| |
|
This document defines a vCard S/MIME Capabilities property and it defines or references values for many algorithms. The SMIME Capability values can also be included in S/MIME messages as a signed attribute and in public key certificates as an extension. The S/MIME Capabilities property is a complement to key property, which together enable usage of S/MIME without an initial exchange of email messages. |
| | IEC 62351 Security Protocol support for GDOI |
| |
|
The IEC 61850 power utility automation family of standards describe methods using Ethernet and IP for distributing control and data frames within and between substations. The IEC 61850-90-5 and IEC 62351-9 standards specify the use of the Group Domain of Interpretation (GDOI) protocol (RFC 6407) to distribute security transforms for some IEC 61850 security protocols. This memo assigns updates GDOI to encode the security transforms and keying material for those security protocols. |
| | Survey Report on PIM-SM Implementations and Deployments |
| |
|
This document provides supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from IETF Proposed Standard to Internet Standard. |
| | A Security Threat Analysis for Routing over Low-Power and Lossy Networks |
| |
|
This document presents a security threat analysis for routing over low-power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. These assessments provide the basis of the security recommendations for incorporation into low-power, lossy network routing protocols. |
| | The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) |
| |
|
The WebSocket protocol enables two-way realtime communication between clients and servers in web-based applications. This document specifies a WebSocket sub-protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in web-oriented deployments. This document normatively updates RFC 3261. |
| | JSON Responses for the Registration Data Access Protocol (RDAP) |
| |
|
This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. |
| | Registration Data Access Protocol Lookup Format |
| |
|
This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. |
| |
|
| |
| | The atypes media feature tag for Session Initiation Protocol (SIP) |
| |
|
This specification defines a new media feature tag called atypes. This new media feature tag indicates the IP address type capabilities of the UA (User Agent) and can aid the routing process and ease the invocation of required functions when heterogeneous (i.e., IPv4 and IPv6) parties are involved in a given SIP session. This specification solves a problem raised in 3GPP TS 24.229 [TS.24229]. |
| | RTP Payload Format for High Efficiency Video Coding |
| |
|
This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) [HEVC], developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC stream over a single as well as multiple RTP flows. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. |
| | PMIPv6-based Distributed Mobility Management |
| |
|
Proxy Mobile IPv6 (PMIPv6) is the network-based mobility management protocol where access network supports the mobility of a mobile node on behalf of the MN. In PMIPv6, the location information of the MN should be registered to Localized Mobility Anchor and communication must be established via the LMA. Therefore, the performance can be degraded due to traffic concentration and congestion possibility. One method to overcome the above problems is to exploit the distributed mobility management (DMM) mechanism to distribute the LMA function to all access routers within the PMIPv6 domain. This letter proposes the fully distributed mobility management mechanism in PMIPv6-based network. In this mechanism, there is no need for the location management function to register the location of the MN. Therefore, the performance is not degraded due to the overhead to query the location of the MN. |
| | Home Documents for HTTP Services: XML Syntax |
| |
|
The current draft for HTTP Home Documents provides a JSON syntax only. This draft provides an XML syntax for the same underlying data model, so that the concept of HTTP Home Documents can be consistently exposed in both JSON- and XML-based HTTP services. Note to Readers Please discuss this draft on the apps-discuss mailing list [7]. Online access to all versions and files is available on github [8]. |
| | Sleepy Devices using CoAP - Possible Solutions |
| |
|
|
| | HTTP Header Compression |
| |
|
This document describes a format adapted to efficiently represent HTTP headers in the context of HTTP/2.0. |
| | Session Description Protocol Support for Tunnels (L2TP) |
| |
|
This document registeres new media type (application/l2tp) to be used with SDP, and clarifies procedure to be used by peers for L2TP tunnels. |
| | Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices |
| |
|
This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies also features to deliver IPv4 connectivity service over an IPv6-only transport. Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. |
| |
|
| |
| | DHCPv6 Failover Requirements |
| |
|
The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers to operate on a single network, however it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. [RFC3315] allows for but does not define any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. |
| | Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) |
| |
|
This document is the Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP. |
| | Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) |
| |
|
This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). |
| | HTTP Digest Update |
| |
|
This documents specifies extensions to the HTTP Digest Authentication mechanism to add support for more digest algorithms to the HTTP Digest Access Authentication scheme. This document also specifies an extension to HTTP Digest Authentication mechanism to allow the server to indicate its character encoding support. |
| | IS-IS Extended Sequence number TLV |
| |
|
This document defines Extended Sequence number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks. |
| | jCal: The JSON format for iCalendar |
| |
| | draft-ietf-jcardcal-jcal-04.txt |
| | Date: |
10/06/2013 |
| | Authors: |
Philipp Kewisch, Cyrus Daboo, Mike Douglass |
| | Working Group: |
JSON data formats for vCard and iCalendar (jcardcal) |
| | Formats: |
txt xml |
|
This specification defines "jCal", a JSON format for iCalendar data. |
| | Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication |
| |
|
This document describes behavior of signalling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. |
| | DNSSEC Trust Anchor Publication for the Root Zone |
| |
|
The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes how such trust anchors are published. |
| | Data Center Mobility based on E-VPN,BGP/MPLS IP VPN,IP Routing and NHRP |
| |
|
This document describes a set of network-based solutions for seamless Virtual Machine mobility in the data center. These solutions provide a toolkit which is based on IP routing, E-VPNs, BGP/MPLS IP VPNs, and NHRP. |
| | Requirements for Automated (Configuration) Management |
| |
|
Given the ever-increasing complexity of the configuration tasks required for the dynamic provisioning of IP networks and services, this document aims at listing the requirements to drive the specification of an automated configuration management framework, including the requirements for a protocol to convey configuration information towards the managed entities. |
| | DECADE: DECoupled Application Data Enroute |
| |
| | draft-alimi-protocol-01.txt |
| | Date: |
10/06/2013 |
| | Authors: |
Richard Alimi, Akbar Rahman, Dirk Kutscher, Yang Yang, Haibin Song, Kostas Pentikousis |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
Content distribution applications, such as those those employing peer-to-peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks. Often, however, content distribution applications use network resources in a counter-productive manner. One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end-host and in-network content distribution mechanisms. This is the capability provided by a DECADE-compatible system, which is introduced in this document. DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources. This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples. |
| | PCP Flow Examples |
| |
|
This document provides a set of examples to illustrate PCP operations. It is a companion document to the base PCP specification. |
| | DNS Root Name Service Protocol and Deployment Requirements |
| |
|
The DNS Root Name service are a critical part of the Internet architecture. The protocol and deployment requirements expected to be implemented for the DNS root name services are defined in this document. Operational requirements are out of scope. This document obsoletes and reclassifies RFC2870 as Historic. |
| | Sleepy Devices using CoAP - Requirements |
| |
|
|
| | Binary Encodings for JavaScript Object Notation: JSON-B,JSON-C,JSON-D |
| |
|
Three binary encodings for JavaScript Object Notation (JSON) are presented. JSON-B (Binary) is a strict superset of the JSON encoding that permits efficient binary encoding of intrinsic JavaScript data types. JSON-C (Compact) is a strict superset of JSON-B that supports compact representation of repeated data strings with short numeric codes. JSON-D (Data) supports additional binary data types for integer and floating point representations for use in scientific applications where conversion between binary and decimal representations would cause a loss of precision. |
| | Harmonizing how applications specify DANE-like usage |
| |
|
This document proposes a specific word usage for specifications of DANE like technology by different protocols/services. DANE is a method for specifying in DNS records acceptable keys/certificates for application servers. |
| | Network-related VM Mobility Issues |
| |
|
This document describes a set of network-related issues presented by the desire to support seamless Virtual Machine mobility in the data center and between data centers. In particular, it looks at the implications of meeting the requirements for "seamless mobility". |
| | Routing for IPv4-embedded IPv6 Packets |
| |
|
This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network. |
| | Requirements for GMPLS applications of PCE |
| |
|
The initial effort of the PCE (Path computation element) WG is specifically focused on MPLS. As a next step, this draft describes functional requirements for GMPLS application of PCE. |
| |
|
| |
| | IPv6 Site Renumbering Gap Analysis |
| |
|
This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements of IPv6 renumbering. Its main content is a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process. |
| | p2mp pw protection for MPLS-TP network |
| |
|
The requirements of MPLS-TP in RFC 5654 include a requirement(R63) that requires MPLS-TP MUST be possible to provide protection for MPLS-TP data plane without any IP forwarding capability and control plane.If applying 1:1 protection mechanism for the p2mp traffic in rfc6718 , it must have a return path to coordinate switch state to select the same path to receive and send traffic packet.For the above problem,this document describes a kind of protection solution to recovery and protect the p2mp traffic under the failure condition. This document is a product of a joint Internet Task Force(IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
| | HTTP/2.0 Discussion: Stored Header Encoding |
| |
|
This memo describes a proposed alternative encoding for headers that combines the best concepts from the proposed Delta and HeaderDiff options with the typed value codecs introduced by previous versions of this draft. |
| | Publishing organization boundaries in the DNS |
| |
|
Often, the organization that manages a subtree in the DNS is is different from the one that manages the tree above it. Rather than describing a particular design, we describe an architecture to publish in the DNS the boundaries between organizations that can be adapted to various policy models. |
| | CoAP High-Level State Option Extension |
| |
|
CoAP is a RESTful application protocol for constrained devices which are often equipped with sensors measuring a physical phenomenon such as temperature on a precise scale. These sensor values are made available by a resource on the CoAP endpoint. However, for many applications it is not necessary to have the full precision a sensor can provide. It's often even enough to only have some high-level states instead of raw values. This document presents a new option for CoAP to dynamically create new resources for a sensor which provides user-defined high-level states instead of raw sensor values. |
| | HTTP Link Hints |
| |
|
This memo specifies "HTTP Link Hints", a mechanism for annotating Web links to HTTP(S) resources with information that otherwise might be discovered by interacting with them. Note to Readers This draft should be discussed on the apps-discuss mailing list; see [apps-discuss]. |
| | An extension to RELOAD to support Direct Response Routing |
| |
| | draft-ietf-p2psip-drr-07.txt |
| | Date: |
09/06/2013 |
| | Authors: |
Ning Zong, XingFeng Jiang, Roni Even, Yunfei Zhang |
| | Working Group: |
Peer-to-Peer Session Initiation Protocol (p2psip) |
| | Formats: |
txt |
|
This document proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential cases where this extension can be used. |
| | An extension to RELOAD to support Relay Peer Routing |
| |
| | draft-ietf-p2psip-rpr-07.txt |
| | Date: |
09/06/2013 |
| | Authors: |
Ning Zong, XingFeng Jiang, Roni Even, Yunfei Zhang |
| | Working Group: |
Peer-to-Peer Session Initiation Protocol (p2psip) |
| | Formats: |
txt |
|
This document proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediate peers and describes the potential use cases where this extension can be used. |
| | Enrollment over Secure Transport |
| |
| | draft-ietf-pkix-est-07.txt |
| | Date: |
09/06/2013 |
| | Authors: |
Max Pritikin, Peter Yee, Dan Harkins |
| | Working Group: |
Public-Key Infrastructure (X.509) (pkix) |
| | Formats: |
txt |
|
This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificate(s). It also supports client-generated public/ private key pairs as well as key pairs generated by the CA. |
| | RADIUS Attributes for IEEE 802 Networks |
| |
|
RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks, as well as clarifications on the usage of the EAP- Key-Name attribute, updating RFC 4072. The attributes defined in this document are usable both within RADIUS and Diameter. |
| |
|
| |
| | MPLS Generic Associated Channel (G-ACh) Advertisement Protocol |
| |
|
The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. |
| | Common YANG Data Types |
| |
|
This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. |
| | The proposal of A Uniform Resource Name (URN) Formal Namespace for the Local Government ICT Platform Project in Japan |
| |
|
This document describes the Namespace Idendifier (NID) 'applic' for Uniform Resource Name (URN) which is used to identify resources released by the Association for Promotion of Public Local Information and Communication (APPLIC). APPLIC publishes and manages specifications that define unique and persistent resources which make use of the namespace. (APPLIC is a nonprofit organization which consists of local governments, private companies and academic experts in Japan.) |
| | Internet Exchange Route Server Operations |
| |
|
The popularity of Internet exchange points (IXPs) brings new challenges to interconnecting networks. While bilateral eBGP sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants. Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead of IXP participation and these systems used by many IXP participants as a preferred means of exchanging routing information. This document describes operational considerations for multilateral interconnections at IXPs. |
| | DHCPv6 Dynamic DNS Reconfiguration |
| |
|
Some networks are expected to support IPv4-only, dual-stack, and IPV6-only hosts at the same time. This makes prioritizing the DNS servers for hosts tricky due to a heterogeneous mix of protocol stacks causing optimal behavior to occur only when the host stack re- initializes. The networks infrastructure is usually well equipped to be aware of single/dual-stack nature of hosts. This specification extends DHCPv6 so that a DHCPv6 Relay Agent can dynamically influence the priority of DNS servers provided to the host, so that the host can use an optimal DNS server for resolution. |
| | Seamless Bidirectional Forwarding Detection (BFD) with MPLS Label Verification Extension |
| |
|
This specification defines a generic simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, and to allow full and partial reachability validations. For MPLS based BFD, extensions to the generic mechanism are defined for BFD to perform a level of label verifications. |
| | Seamless Bidirectional Forwarding Detection (BFD) for IP |
| |
|
This specification defines procedures to use Seamless Bidirectional Forwarding Detection (BFD) in IP and IP signalled MPLS environments. |
| | Seamless Bidirectional Forwarding Detection (BFD) for Segment Routing (SR) |
| |
|
This specification defines procedures to use Seamless Bidirectional Forwarding Detection (BFD) in a Segment Routing (SR) based environment. |
| | PKIX Operations: Certificate Status |
| |
|
[abs] |
| | Detecting VXLAN Segment Failure |
| |
|
This proposal describes a mechanism that can be used to detect Data Path Failures and sanity of VXLAN Control and Data Plane for a given VXLAN Segment. This document defines the following: o Information carried in a VXLAN "Echo Request", and o "Echo Reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the Echo Request and reply. |
| | Programmatic Interfaces to On-demand Network Services |
| |
|
One of the major features or requirements of Cloud is on-demand CRUD (Create / Read / Update / Delete) of Cloud resources or associated resources. The on-demand feature dictates that resources are CRUD in a time-frame in the order of seconds or few minutes since the arrival of the resource CRUD request. Many network resources cannot be CRUD in that time-frame. With the support of programmable networking (or SDN) in the model of I2RS will facilitate programming of network resources rapidly, thus facilitating CRUD of Cloud or related network resources on-demand. Network resources associated with many network services can be either a Cloud resource or directly associated with a Cloud resource. These resources should be CRUD on-demand in Cloud timescale. In this draft, employing Hybrid (virtual) Cloud as a use case and using I2RS as the "model", we will define few requirements for programmable on-demand interfaces to network services or I2NS. |
| | IP Storage: IPsec Requirements Update for IPsec v3 |
| |
|
RFC 3723 includes requirements for IPsec usage with IP Storage protocols (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs). This document updates those requirements to IPsec v3 (RFC 4301 and related RFCs) and updates implementation requirements to reflect developments in cryptography since RFC 3723 was published. [RFC Editor: The "Updates:" list above has been truncated by xml2rfc. The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if approved) ] |
| |
|
| |
| | Diameter Applications Design Guidelines |
| |
|
The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. It is meant as a guidelines document and therefore as informative in nature. |
| | Diameter Overload Control Requirements |
| |
|
When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce sending traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in congestion collapse. The existing Diameter mechanisms, listed in Section 3 are not sufficient for this purpose. This document describes the limitations of the existing mechanisms in Section 4. Requirements for new overload management mechanisms are provided in Section 7. |
| | Auto Discovery VPN Problem Statement and Requirements |
| |
|
This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution will address these requirements. |
| | The application/json Media Type for JavaScript Object Notation (JSON) |
| |
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. |
| | Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) |
| |
|
This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). |
| | Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Enhanced Mode |
| |
|
This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to satisfy the requirements of the Layer 1 Virtual Private Network (L1VPN) Enhanced Mode. L1VPNs provide customer services and connectivity at layer 1 over layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Enhanced Mode of operation may also include exchange of routing information between the layer 1 network and the customer domain. |
| | OCSP-lite - Revocation of raw public keys |
| |
|
This document provides an online mechanism for checking the revocation status of raw public keys. The mechanism is based on its older brother for X.509 certificates, OCSP. Note Discussion and suggestions for improvement are requested, and should be sent to tls@ietf.org. |
| | Diameter Overload Control Solution Issues |
| |
|
The Diameter Maintenance and Extensions (DIME) working group has undertaken an "overload control" work item, with the goal of standardizing a mechanism to allow Diameter nodes to report overload information among themselves. Requirements currently include, among others, the need to accurately report the scope of overload conditions, and the ability to report overload information between nodes that are not directly connected at the transport layer. These requirements introduce complex issues. This document describes those issues, in the hope that it will assist the working group's decision process. |
| | Side effect of DNSSEC: an increase of DS queries |
| |
|
A significant increase of periodic DS queries is observed at top level domain (TLD) DNS servers. Currently, almost all of periodic DS queries come from DNSSEC validators and are queries for unsigned delegations. The reason of the increase is low NCACHE TTL value and DS nonexistence. This phenomena is DNSSEC protocol and DNS parameter issue. DS queries will increase as DNSSEC validators will increase. |
| | Interoperability Impacts of IPv6 Interworking with Existing IPv4 SIP Implementations |
| |
|
This document captures potential impacts to IPv4 SIP implementations when interworking with IPv6 SIP implementations. Although some amount of interworking translation will occur at the network and application layers, an IPv4 SIP application may still encounter a SIP message with some IPv6 values in it, resulting in unforeseen error conditions. Such potential scenarios will be identified in this document so that SIP application developers can define solutions to handle these cases. Note, this document is not intended to be an exhaustive list, rather to provide an overview of some of the more commonly encountered potential scenarios. |
| | Talk - Comet Stream Protocol |
| |
|
Talk is a very simple way of communicating in real-time over HTTP. |
| | OAuth 2.0 Dynamic Client Registration Protocol |
| |
|
This specification defines an endpoint and protocol for dynamic registration of OAuth 2.0 Clients at an Authorization Server and methods for the dynamically registered client to manage its registration. |
| | IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization |
| |
|
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes. This document defines an extension to IMAP (RFC 3501). |
| | A Reputation Response Set for Email Identifiers |
| |
|
This document defines a response set for describing assertions a reputation service provider can make about email identifers, for use in generating reputons. |
| | A Media Type for Reputation Interchange |
| |
|
This document defines the format of reputation response data ("reputons"), the media-type for packaging it, and definition of a registry for the names of reputation applications and response sets. |
| | A Reputation Query Protocol |
| |
|
This document defines a mechanism to conduct queries for reputation information over the Hypertext Transfer Protocol using JSON as the payload meta-format. |
| | A Model for Reputation Reporting |
| |
| | draft-ietf-repute-model-05.txt |
| | Date: |
06/06/2013 |
| | Authors: |
Nathaniel Borenstein, Murray Kucherawy, Andrew Sullivan |
| | Working Group: |
Reputation Services (repute) |
| | Formats: |
txt |
|
This document describes a general architecture for a reputation-based service and a model for requesting reputation-related data over the Internet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC4101 for describing a protocol model. |
| | iSCSI Extensions for RDMA Specification |
| |
|
iSCSI Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol. This document obsoletes RFC 5046. |
| |
|
| |
| | The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) |
| |
| | draft-ietf-avtcore-aria-srtp-02.txt |
| | Date: |
05/06/2013 |
| | Authors: |
Woo-Hwan Kim, Jungkeun Lee, Dong-Chan Kim, Je-Hong Park, Daesung Kwon |
| | Working Group: |
Audio/Video Transport Core Maintenance (avtcore) |
| | Formats: |
pdf txt |
|
This document describes the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. |
| | Requirements for Distributed Mobility Management |
| |
|
This document defines the requirements for Distributed Mobility Management (DMM) in IPv6 deployments. The hierarchical structure in traditional wireless networks has led to deployment models which are in practice centralized. Mobility management with logically centralized mobility anchoring in current mobile networks is prone to suboptimal routing and raises scalability issues. Such centralized functions can lead to single points of failure and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. The objective is to enhance mobility management in order to meet the primary goals in network evolution, i.e., improve scalability, avoid single points of failure, enable transparent mobility support to upper layers only when needed, and so on. Distributed mobility management must be secure and may co-exist with existing network deployments and end hosts. |
| | IPv4-IPv6 Multicast: Problem Statement and Use Cases |
| |
|
This document discusses issues and requirements raised by IPv4-IPv6 multicast interconnection and co-existence scenarios. It also discusses various multicast use cases which may occur during IPv6 transitioning. |
| | Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) |
| |
|
SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=' line), connection data ('c=' line), and titles ('i=' line for each session or media). |
| | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Network Management Protocols |
| |
|
This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options providing lists of IP addresses that can be used to locate network management services, specifically for the collection of logs and of Simple Network Management Protocol (SNMP) notifications. |
| | Event Publishing Extensions to iCalendar |
| |
|
This specification introduces a number of new iCalendar properties which are of particular use for event publishers and in social networking. |
| | CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) |
| |
|
This document describes suggested practices for combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). Such practices aim to provide a single fully featured real-time communication service by using complementary subsets of features from each of the protocols. Typically such subsets would include telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for either SIP or XMPP. However, implementing the practices outlined in this document may require modifying or at least reconfiguring existing client and server-side software. Also, it is not the purpose of this document to make recommendations as to whether or not such combined use should be preferred to the mechanisms provided natively by each protocol (for example, SIP's SIMPLE or XMPP's Jingle). It merely aims to provide guidance to those who are interested in such a combined use. |
| | Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks |
| |
|
This document defines a framework and the associated control plane requirements for the GMPLS based control of flexi-grid DWDM networks. To allow efficient allocation of optical spectral bandwidth for high bit-rate systems, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended the recommendations [G.694.1] and [G.872] to include the concept of flexible grid. A new DWDM grid has been developed within the ITU-T Study Group 15 by defining a set of nominal central frequencies, channel spacings and the concept of "frequency slot". In such environment, a data plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum. |
| | Software-Defined Networking: A Service Provider's Perspective |
| |
|
Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims at contributing to the clarification of the SDN landscape by discussing a service provider's perspective on requirements, issues and other considerations about SDN. It is not meant to endlessly discuss what SDN truly means, but rather to suggest a functional taxonomy of the techniques that can be used under a SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification. |
| | Finding the Authoritative Registration Data (RDAP) Service |
| |
|
This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers, using data available in IANA registries. |
| | Child To Parent Synchronization in DNS |
| |
|
This document specifies how a child zone in the DNS can publish a record that can indicate that a parental agent may copy and process certain records from the child zone. The existence and change of the record may be monitored by a parental agent to either assist in transferring or automatically transfer data from the child to the parent. |
| | Trust models of the Web PKI |
| |
|
This is one of a set of documents to define the operation of the Web PKI. It describes the currently deployed Web PKI trust model and common variants. |
| | Learning NAT64 PREFIX64s using PCP |
| |
|
This document defines a new PCP extension to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This extension is needed for successful communications when IPv4 addresses are used in referrals. |
| |
|
| |
| | Relative Location Representation |
| |
|
This document defines an extension to PIDF-LO (RFC4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described. Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system to allow display of the map with the reference point and the relative offset. |
| | BGP Optimal Route Reflection (BGP-ORR) |
| |
|
[RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress point in cases where no higher priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the egress point closest to the route reflector - and not necessarily closest to the RR clients. Section 11 of [RFC4456] describes a deployment approach and a set of constraints which, if satsified, would result in the deployment of route reflection yielding the same results as the iBGP full mesh approach. Such a deployment approach would make route reflection compatible with the application of hot potato routing policy. As networks evolved to accommodate architectural requirements of new services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes two new solutions which can be deployed to facilitate the application of closest exit point policy centralized route reflection deployments. |
| | Additional Diffie-Hellman Tests for IKEv2 |
| |
|
This document adds a small number of mandatory tests required for the secure operation of IKEv2 with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called DSA groups. This document updates the IKEv2 protocol, RFC 5996. |
| | Home Agent Initiated Flow Binding for Mobile IPv6 |
| |
|
There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node such as moving a flow from one access network to another based on the network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Home agent initiated flow bindings are supported for both IPv4 and IPv6 enabled mobile nodes. |
| | Why Operators Filter Fragments and What It Implies |
| |
| | draft-taylor-v6ops-fragdrop-01.txt |
| | Date: |
04/06/2013 |
| | Authors: |
Joel Jaeggli, Lorenzo Colitti, Warren Kumari, Eric Vyncke, Merike Kaeo, Tom Taylor |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
This memo was written to make application developers and network operators aware of the significant possibility that IPv6 packets containing fragmentation extension headers may fail to reach their destination. Some protocol or application assumptions about the ability to use messages larger than a single packet may accordingly not be supportable in all networks or circumstances. This memo provides observational evidence for the dropping of IPv6 fragments along a significant number of paths, explores the operational impact of fragmentation and the reasons and scenarios where drops occur, and considers the effect of fragment drops on applications where fragmentation is known to occur, particularly including DNS. |
| | Compact representation of an elliptic curve point |
| |
|
This document defines a format for efficient storage representation of an elliptic curve point over prime fields, suitable for use with any IETF format or protocol. |
| | ISSU Benchmarking Methodology |
| |
|
Modern forwarding devices attempt to minimize any control and data plane disruptions while performing planned software changes, by implementing a technique commonly known as an In Service Software Upgrade (ISSU). This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT) subject to an ISSU event. |
| | Finding the Authoritative Registration Data (RDAP) Server |
| |
|
This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers. |
| | Definitions and Metrics for Data Center Benchmarking |
| |
| | draft-dcbench-def-00.txt |
| | Date: |
04/06/2013 |
| | Authors: |
Jacob Rapp, Lucien Avramov |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The purpose of this informational document is to establish definitions, discussion and measurement techniques for data center benchmarking. Also, it is to introduce new terminologies applicable to data center performance evaluations. The purpose of this document is not to define the test methodology, but rather establish the important concepts when one is interested in benchmarking network equipment in the data center. |
| | PKIX over Secure HTTP (POSH) |
| |
|
This document defines two methods that make it easier to deploy certificates for proper server identity checking in application protocols. The first method enables a TLS client to obtain a TLS server's end-entity certificate over secure HTTP as an alternative to standard Public Key Infrastructure using X.509 (PKIX) and DNS-Based Authentication of Named Entities (DANE). The second method enables a source domain to securely delegate an application to a derived domain using HTTPS redirects. |
| | Provisioning Lightweight 4over6 (lw4o6) with the Port Control Protocol (PCP) |
| |
|
This memo defines the procedures that a Lightweight B4 uses for provisioning its parameters with the Port Control Protocol. |
| | The 'via' keyword in RPSL Policy Specifications |
| |
|
This document defines the 'via' keyword which can be used in RPSL policy specifications to publish desired routing policy regarding non-adjacent networks. |
| | Reflections On Host Firewalls |
| |
|
In today's Internet, the need for firewalls is generally accepted in the industry and indeed firewalls are widely deployed in practice. Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a firewall. It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication. In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward. |
| | NSA's Cryptographic Message Syntax (CMS) Key Management Attributes |
| |
|
This document defines key management attributes used by the National Security Agency. The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages. |
| | PIM-DM Optimizations for Large LANs |
| |
|
Optimizations to the PIM-DM protocol [RFC3973] are proposed that dramatically reduce the PIM-DM routing overhead on local area networks containing large numbers of PIM routers. These optimizations reduce the likelihood of two or more routers emitting redundant JOIN or PRUNE messages onto the same LAN. While these optimizations are of general applicability to large LANs, they were motivated in particular by performance requirements for supporting PIM-DM across LANs emulated by IP tunneling over large wireless MANETs. PIM-DM routers supporting these optimizations will interoperate with standard PIM-DM as defined in RFC 3973, even on the same LAN. However, to obtain maximum benefit from these optimizations, all PIM-DM routers on the LAN SHOULD support them. |
| | Generic UDP Encapsulation for IP Tunneling |
| |
|
This document describes a method of encapsulating arbitrary protocols within UDP and GRE headers. In this encapsulation, the source UDP port may be used as an entropy field for purposes of load balancing while the payload protocol may be identified by the GRE Protocol Type. |
| | Protocol to Access Spectrum Database |
| |
| | draft-ietf-paws-protocol-05.txt |
| | Date: |
04/06/2013 |
| | Authors: |
Vincent Chen, Subir Das, Lei Zhu, John Malyar, Pete McCann |
| | Working Group: |
Protocol to Access WS database (paws) |
| | Formats: |
txt |
|
Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). |
| | Shared Use of Experimental TCP Options |
| |
|
This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection. It uses a new IANA TCP experiment identifier, and is also robust to experiments that are not registered and those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. |
| | New Performance Metrics Composition Framework for Multiparty Services |
| |
|
One of the best chances for a Service Provider to face the complex growth of IP Services, and their challenging requirements/SLAs along the Core network, is to enrich the current Performance metrics - mainly derived from a "Network-Oriented point of view", and therefore a general perspective, not focused on specific services - with some more Performance factors, so to include a "Service-Oriented point of view", more centred on the particular kind of service, with its own characteristics in terms of protocol, application, manageability, and so on. Almost nothing about this new approach has been standardized yet for the core network. To achieve the above goal, and starting from the one-to-group performance metrics outlined in RFC 5644 [RFC5644], a new metrics composition/aggregation framework is proposed in this memo, where the main focus is on multiparty communications (e.g. video providers, online biding, online stock market, etc.). Finally this memo is tuned to RFC 6390 [RFC6390] in terms of scopes, framework concepts, and need to widen the current performance metrics depending on the application, service etc. |
| | Spatial Aggregation Metrics for Multipary Services |
| |
|
One of the best chances for a Service Provider to face the complex growth of IP Services, and their challenging requirements/SLAs along the Core network, is to enrich the current Performance metrics - mainly derived from a Network-oriented point of view, and therefore a general perspective, not focused on specific services - with some more Performance factors, so to include a Service-oriented point of view, more centred on the particular kind of service, with its own characteristics in terms of protocol, application, manageability, and so on. To achieve the above goal, and starting from the one-to-group performance metrics outlined in RFC 5644 [RFC5644], an effort to a deeper analysis and definition of spatial aggregation metrics (as a part of the framework for metric composition defined in RFC 5835 [RFC5835])is proposed in this memo, where the main focus is on multiparty communications (e.g. video providers, online biding, online stock market, etc.). This memo lends itself to passive measurement as well as active measurement. Finally this memo is tuned to RFC 6390 [RFC6390] in terms of scopes, framework concepts, and need to widen the current performance metrics depending on the application, service etc. |
| |
|
| |
| | Network Address Translation (NAT) Behavioral Requirements Updates |
| |
|
This document clarifies and updates several requirements of RFC4787, RFC5382 and RFC5508 based on operational and development experience. The focus of this document is NAPT44. |
| | IMIX Genome: Specification of variable packet sizes for additional testing |
| |
|
Benchmarking Methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, and so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX". The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking device and deployment will not be appropriate for another. However, the mix of sizes may be known and the tester may be asked to augment the fixed size tests. To address this need, and the perpetual goal of specifying repeatable test conditions, this draft defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes, and other forms of mixed size specification. |
| | Best Practices for HTTP-CoAP Mapping Implementation |
| |
| | draft-ietf-core-http-mapping-00.txt |
| | Date: |
03/06/2013 |
| | Authors: |
Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk |
| | Working Group: |
Constrained RESTful Environments (core) |
| | Formats: |
txt xml |
|
This draft provides reference information for HTTP-CoAP protocol translation proxy implementors, focusing primarily on the reverse proxy case. It details deployment options, discusses possible approaches for URI mapping, and provides a set of guidelines and considerations related to protocol translation. |
| | CoRE Interfaces |
| |
|
This document defines well-known REST interface descriptions for Batch, Sensor, Parameter and Actuator types for use in contrained web servers using the CoRE Link Format. A short reference is provided for each type that can be efficiently included in the interface description attribute of the CoRE Link Format. These descriptions are intended to be for general use in resource designs or for inclusion in more specific interface profiles. In addition, this document defines the concepts of Function Set and Binding. The former is the basis element to create RESTful profiles and the latter helps the configuration of links between resources located on one or more endpoints. |
| | CoRE Resource Directory |
| |
|
In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. |
| | Modification to Default Value of SOL_MAX_RT |
| |
|
This document updates RFC 3315 by redefining the default values for SOL_MAX_RT and INF_MAX_RT, and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT and INF_MAX_RT with a new value. |
| | Hub and Spoke Multipoint Label Switched Path Tunnels |
| |
|
There are applications that require bi-directional, co-routed and guaranteed communication from a root node to several leaf nodes in a hub and spoke fashion. To meet such application requirements in a Multi-protocol Label Switching (MPLS) network this draft defines a Hub and Spoke Multipoint Traffic Engineered Label Switched Path (HSMP TE LSP) with resource reservations for guaranteed communication. This draft also defines a protocol to setup such LSPs by re-using and extending P2MP RSVP-TE. |
| | PIM-SM DR Priority Auto-Adjustment |
| |
|
This document defines some mechanisms for automatically adjusting the Protocol Independent Multicast (PIM) Designed Router (DR) priority according to the status of the tracked interface. This approach can be used to realize DR auto-switchover in case the DR loses the route to multicast source or Rendezvous Point (RP). |
| | Problem Details for HTTP APIs |
| |
|
This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response, to avoid the need to invent new error response formats for HTTP APIs. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. |
| | Enhanced Route Refresh Implementation Report |
| |
|
This document provides an implementation report for Enhanced Route refresh as defined in draft-ietf-idr-bgp-enhanced-route-refresh-03. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. |
| | SA46T Prefix Resolution (SA46T-PR) |
| |
|
This document specifies SA46T Prefix Resolution (SA46T-PR) specification. SA46T-PR is almost same as SA46T, however method of generation of outer IPv6 address is defferent. SA46T is backbone network based approach, however SA46T-PR is stub network based approch. |
| | SA46T Prefix Translator (SA46T-PT) |
| |
|
This document specifies SA46T Prefix Translator (SA46T-PT) specification. SA46T-PT expand IPv4 network plane by connecting SA46T domain and SA46T-PR domain. SA46T-PT translate prefix part of SA46T address and SA46T-PR address both are IPv6 address. SA46T-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. |
| | PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem |
| |
| | draft-pan-aqm-pie-00.txt |
| | Date: |
03/06/2013 |
| | Authors: |
Rong Pan, Preethi Natarajan, Chiara Piglione, Mythili Prabhu |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
Bufferbloat is a phenomenon where excess buffers in the network cause high latency and jitter. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and jitter degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. We present here a lightweight design, PIE(Proportional Integral controller Enhanced) that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamp, so it incurs very small overhead and is simple enough to implement in both hardware and software. |
| | Secure Bootstrapping Solution for Resource-Constrained Devices |
| |
|
We present a solution to initially configure the network of resource constrained nodes securely, a.k.a., secure bootstrapping. The solution is based on EAP-TLS authentication with the use of raw public keys as certificates. |
| | Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication |
| |
|
RFC 6513 described a method to support bidirectional C-flow using "Partial Mesh of MP2MP P-Tunnels". This document describes how partial mesh of MP2MP P-Tunnels can be simulated with Ingress Replication, instead of a real MP2MP tunnel. |
| | Use of OSPF-MDR in Single-Hop Broadcast Networks |
| |
|
RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks. |
| | OSPF Traffic Engineering (TE) Metric Extensions |
| |
|
In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to OSPF TE [RFC3630] such that network performance information can be distributed and collected in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. |
| | How to Write an RTP Payload Format |
| |
|
This document contains information on how to best write an RTP payload format. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions that can be used when writing an RTP payload format. |
| | LDP extensions for Pseudowire Binding to LSP Tunnels |
| |
|
Many transport services require that user traffic, in the forms of Pseudowires (PW), to be delivered on a single co-routed bidirectional LSP or two LSPs that share the same routes. In addition, the user traffic may traverse through multiple transport networks. This document specifies an optional extension in LDP that enable the binding between PWs and the underlying LSPs. |
| | Security Services for the Registration Data Access Protocol |
| |
|
The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. This document describes information security services including authentication, authorization, availability, data confidentiality, and data integrity for RDAP. |
| |
|
| |
| | Content Distribution Network Interconnection (CDNI) Requirements |
| |
|
Content Delivery Networks (CDNs) are frequently used for content delivery. As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers and Enterprise Service Providers are also deploying their own CDNs. To deliver contents from the Content Service Protect (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. |
| | CDNI Logging Interface |
| |
| | draft-ietf-cdni-logging-03.txt |
| | Date: |
31/05/2013 |
| | Authors: |
Gilles Bertrand, Iuniana Oprescu, Francois Le Faucheur, Roy Peterkofsky |
| | Working Group: |
Content Delivery Networks Interconnection (cdni) |
| | Formats: |
txt |
|
This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. |
| | Shared Memory Communications over RDMA |
| |
|
This document describes the Shared Memory Communications over RDMA (SMC-R) protocol. This protocol provides RDMA communications to TCP endpoints in a manner that is transparent to socket applications. It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, transparent high availability and load balancing when redundant RDMA network paths are available, and it maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data. |
| | URI Signing for CDN Interconnection (CDNI) |
| |
| | draft-leung-cdni-uri-signing-02.txt |
| | Date: |
31/05/2013 |
| | Authors: |
Kent Leung, Francois Le Faucheur, Bill Downey, Ray van Brandenburg, Scott Leibrand |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
xml txt |
|
This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a candidate URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access request for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. |
| | A Comparison of IPv6 over IPv4 Tunnel Mechanisms |
| |
|
This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not (yet) widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them. |
| | Compression of IPsec AH and ESP Headers for Constrained Environments |
| |
|
This document describes the header compression mechanisms for the IPsec [RFC4301] based on the encoding scheme standardized in [RFC6282]. The IPsec Authentication Header (AH) and Encapsulated Security Payload (ESP) headers are compressed using Next Header Compression (NHC) defined in [RFC6282]. This document does not invalidate any encoding schemes proposed in 6LoWPAN [RFC6282] but rather complements it with compressed IPsec using the free bits in the IPv6 Extension Header encoding. |
| | RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics reporting |
| |
|
An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/Multicast MPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR Block are not dependent on Program specific information carried in MPEG TS. |
| |
|
| |
| | TCP modifications for Congestion Exposure |
| |
|
Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). |
| | Flow Selection Techniques |
| |
|
Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. |
| | Requirements for Ethernet VPN (E-VPN) |
| |
| | draft-ietf-l2vpn-evpn-req-03.txt |
| | Date: |
30/05/2013 |
| | Authors: |
Ali Sajassi, Rahul Aggarwal, Nabil Bitar, Aldrin Isaac |
| | Working Group: |
Layer 2 Virtual Private Networks (l2vpn) |
| | Formats: |
txt |
|
The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multi-homing with all-active forwarding is not supported and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) LSPs for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (E-VPN) solution which addresses the above issues. |
| | Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path |
| |
|
Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively. |
| | Deterministic Usage of DSA and ECDSA Digital Signature Algorithms |
| |
|
This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard DSA and ECDSA digital signatures, and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures, but can be more easily implemented in various environments since they do not need access to a source of high quality randomness. |
| | Inter-Carrier OAM Requirements |
| |
|
This draft specifies requirements for inter-carrier OAM supporting end-to-end OAM functionality and mechanisms development in a multi- operator environment. It reviews the already proposed OAM requirements addressed in IETF [RFC5706, RFC5860], ITU-T [Y.1730],MEF [MEFOAM] and IEEE [IEEE1, IEEE2] which were mainly proposed on a per transport technology basis, but aims to differentiate and focus on the requirements and additional requirements resulting from inter- operator considerations only. |
| | Retrieving the Capabilities of a PCP-controlled Device |
| |
|
This document extends Port Control Protocol (PCP) with the ability to retrieve the capabilities of PCP-controlled device: CAPABILITY Option. |
| | Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) |
| |
|
This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP). |
| | Trust Router Problem Statement |
| |
|
There are a number of problems with using the current AAA framework for doing access control, this document looks at a number of these issues and poses some questions about how to create a new trust router system. |
| | IPv6 Performance and Diagnostic Metrics Destination Option |
| |
|
To diagnose problems for a number of Enterprise Data Center Operators (EDCO), two metrics are critical for timely end-to-end problem resolution, both real-time and after the fact, without impacting an operational production network. They are: packet sequence number and packet timestamp. Packet sequence number is required for diagnostics. Packet timestamp is required to calculate end-to-end response time. Current methods are inadequate for these purposes because they assume unreasonable access to intermediate devices, are cost prohibitive, require infeasible changes to a running production network, and / or do not provide timely data. This document solves these problems with a new destination option, the Performance and Diagnostic Metrics destination option (PDM). |
| | End-to-end Response Time Needed for IPv6 Diagnostics |
| |
|
For a number of Enterprise Data Center Operators (EDCO) both real- time and after the fact problem resolution is critical. Two metrics are critical for timely end-to-end problem resolution, without impacting an operational production network. They are: packet sequence number and packet timestamp. Packet sequence number is required for diagnostics. Packet timestamp is required to calculate end-to-end response time. Current methods are inadequate for these purposes because they assume unreasonable access to intermediate devices, are cost prohibitive, require infeasible changes to a running production network, or do not provide timely data. This document provides the background and rationale for the packet timestamp which is a part of the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). |
| | IPv6 Packet Sequence Number Needed |
| |
|
For a number of Enterprise Data Center Operators (EDCO) both real- time and after the fact problem resolution is critical. Two metrics are critical for timely end-to-end problem resolution, without impacting an operational production network. They are: packet sequence number and packet timestamp. Packet sequence number is required for diagnostics. Packet timestamp is required to calculate end-to-end response time. Current methods are inadequate for these purposes because they assume unreasonable access to intermediate devices, are cost prohibitive, require infeasible changes to a running production network, or do not provide timely data. This document provides the background and rationale for the packet sequence number which is a part of the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). |
| | Recommended Usage of IPv6 PDM Option |
| |
|
For a number of Enterprise Data Center Operators (EDCO) both real- time and after the fact problem resolution is critical. Two metrics are critical for timely end-to-end problem resolution, without impacting an operational production network. They are: packet sequence number and packet timestamp. Packet sequence number is required for diagnostics. Packet timestamp is required to calculate end-to-end response time. Current methods are inadequate for these purposes because they assume unreasonable access to intermediate devices, are cost prohibitive, require infeasible changes to a running production network, or do not provide timely data. This document details the recommended usage for the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). |
| | IANA Registries for BGP Extended Communities |
| |
|
This document reorganizes the IANA Registries for the type values and sub-type values of BGP Extended Communities attribute and the BGP IPv6-Address-Specific Extended Communities attribute. This is done in order to remove inter-dependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations, and thus do not affect protocol implementations. The changes will however impact the "IANA Considerations" sections of future protocol specifications. This document updates RFCs 4360 and 5701. |
| | IMAP4 Extensions for Quick Mailbox Resynchronization |
| |
|
This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). |
| | Unified IPv4-in-IPv6 Softwire CPE |
| |
|
Transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity over IPv6-only provider networks. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo describes a specification whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services. |
| |
|
| |
| | Transmission of IPv6 Extension Headers |
| |
|
Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. |
| | Evaluation of existing GMPLS encoding against G.709v3 Optical Transport Networks (OTN) |
| |
|
ITU-T recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling methods against the G.709 [G.709-2012] OTN networks. |
| | Group Communication for CoAP |
| |
|
CoAP is a RESTful transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. |
| | Hypertext Transfer Protocol version 2.0 |
| |
| | draft-ietf-httpbis-http2-03.txt |
| | Date: |
29/05/2013 |
| | Authors: |
Mike Belshe, Roberto Peon, Martin Thomson, Alexey Melnikov |
| | Working Group: |
Hypertext Transfer Protocol Bis (httpbis) |
| | Formats: |
txt xml |
|
This specification describes an optimized expression of the syntax of the Hypertext Transfer Protocol (HTTP). The HTTP/2.0 encapsulation enables more efficient use of network resources and reduced perception of latency by allowing header field compression and multiple concurrent messages on the same connection. It also introduces unsolicited push of representations from servers to clients. This document is an alternative to, but does not obsolete the HTTP/1.1 message format or protocol. HTTP's existing semantics remain unchanged. |
| | Autonomous System (AS) Reservation for Private Use |
| |
|
This document describes the reservation of Autonomous System numbers (ASNs) that are for Private Use only and MUST NOT be advertised to the Internet, known as Private Use ASNs. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10. |
| | Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) |
| |
|
Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. In the past, the Cryptographic Message Syntax has provided a binary secure object format based on ASN.1. Over time, the use of binary object encodings such as ASN.1 has been overtaken by text-based encodings, for example JavaScript Object Notation. This document defines a set of use cases and requirements for a secure object format encoded using JavaScript Object Notation, drawn from a variety of application security mechanisms currently in development. |
| | The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) |
| |
|
This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-time Streaming Protocol (RTSP). Each technique includes a description on how it would be used, the security implications of using it and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP 2.0. |
| | Best practices and Requirements for delivering Long Tail personalized content delivery over CDN Interconnections |
| |
|
The content desire of users is evolving from most popular to long tail personalized content. This document discusses the best practices and requirements for delivering long tail personalized content in CDN Interconnection scenarios. |
| | Generic Routing Encapsulation (GRE) Fragmentation Strategy |
| |
|
This memo documents a GRE fragmentation strategy upon which many vendors have converged. Specifically, it defines procedures to be executed by GRE ingress routers. It is published so that those building new implementations will be aware of best common practice. It is also published so that those building applications over GRE will understand how GRE works. |
| | Connectivity Provisioning Negotiation Protocol (CPNP) |
| |
|
This document specifies the Connectivity Provisioning Negotiation Protocol (CPNP) which is used to facilitate the dynamic negotiation of connectivity provisioning parameters between a Customer and a Provider. |
| | Authenticated Identity Management in the Session Initiation Protocol (SIP) |
| |
|
The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. |
| | Mapping of Address and Port with Encapsulation (MAP) |
| |
| | draft-ietf-softwire-map-07.txt |
| | Date: |
29/05/2013 |
| | Authors: |
Ole Troan, Wojciech Dec, Xing Li, Congxiao Bao, Satoru Matsushima, Tetsuya Murakami, Tom Taylor |
| | Working Group: |
Softwires (softwire) |
| | Formats: |
txt |
|
This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports. |
| |
|
| |
| | XML Media Types |
| |
|
This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. Major differences from [RFC3023] are alignment of charset handling for text/xml and text/xml-external-parsed-entity with application/ xml, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. |
| | Provisioning IPv4 Configuration Over IPv6 Only Networks |
| |
|
As IPv6 becomes more widely adopted, some service providers are taking the approach of deploying IPv6 only networks, without dual- stack functionality for IPv4. However, access to IPv4 based services is still an ongoing requirement and approaches such as IPv4-in-IPv6 softwire tunnels are being developed to meet this need. In order to provision end-user's hosts with the necessary IPv4 configuration, a number of different mechanisms have been proposed. This memo discusses the benefits and drawbacks of each, with the aim of recommending a single approach as the basis for future work. |
| | Additional Data related to an Emergency Call |
| |
|
When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call or the caller which the PSAP may be able to use. This document describes data structures and a mechanism to convey such data to the PSAP. The mechanism uses a Uniform Resource Identifier (URI), which may point to either an external resource or an object in the body of the SIP message. The mechanism thus allows the data to be passed by reference (when the URI points to an external resource) or by value (when it points into the body of the message). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. |
| | JSON Web Algorithms (JWA) |
| |
|
The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. |
| | JSON Web Encryption (JWE) |
| |
|
JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. |
| | JSON Web Key (JWK) |
| |
|
A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. |
| | JSON Web Signature (JWS) |
| |
|
JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. |
| | Default Nickname Based Approach for Multilevel TRILL |
| |
|
Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. |
| | TRILL Fault Management |
| |
| | draft-tissa-trill-oam-fm-02.txt |
| | Date: |
28/05/2013 |
| | Authors: |
Tissa Senevirathne, Norman Finn, Samer Salam, Deepak Kumar, Donald Eastlake, Sam Aldrin, Li Yizhou |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
TRILL OAM Fault Management specification is presented in this document. Methods in this document follow the IEEE 802.1 CFM framework and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL specific applications or where a different set of information is required other than IEEE 802.1 CFM. |
| | Using PCP to Reveal a Host behind NAT |
| |
|
This document describes how to use PCP to retrieve the identity of a host behind a NAT. Two use cases are discussed and the PCP applicability is analyzed. This document extends PCP with a new OpCode called QUERY Opcode. The proposed mechanism is valid for all NAT flavors including NAT44, NAT64 or NPTv6. |
| | Creating an IETF Working Group Draft |
| |
|
The productive output of IETF working groups is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document it usually "adopts" it as a working group draft. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses the process of creating formal working group drafts that are targeted for publication. |
| | Macros Nixed by Major Providers |
| |
|
SPF is a popular tool for managing email blocking issues. It has also helped reduce backscatter related with Non-Delivery Notifications as was intended. A practically unused feature is the SPF macro capability that SPFbis still in part retains. This feature greatly diminishes SPF's utility and actually threatens email interchange, especially when used in conjunction with secondary policy layers when also ignored by major providers. The macro mechanism is also unable to cope with internationalization, and is found in virtually none of the published resource records. It is counter productive to retain the largely unused and often unsupported macro feature, despite efforts expended to develop the macro language. |
| | Using UDP Checksum Trailers in the Network Time Protocol (NTP) |
| |
|
The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To faciliate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Trailer, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP checksum field. The behavior defined in this document is interoperable with existing NTP implementations. |
| | UDP Checksum Trailer in OWAMP and TWAMP |
| |
|
The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission timestamp into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Trailer, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations. |
| | JSON Web Token (JWT) |
| |
|
JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The suggested pronunciation of JWT is the same as the English word "jot". |
| | RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting |
| |
|
This document defines two RTP Control Protocol (RTCP) Extended Report (XR) Blocks that allow the reporting of synchronization delay and offset metrics for use in a range of RTP applications. |
| |
|
| |
| | A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) |
| |
|
This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. |
| | Delayed Duplication Attribute in the Session Description Protocol |
| |
|
A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to simply duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as Time-shifted Redundancy, Temporal Redundancy or simply Delayed Duplication. This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. |
| | Duplication Grouping Semantics in the Session Description Protocol |
| |
|
Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework [RFC5888]. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for RTP streams using SSRC multiplexing. |
| | Allocating and Retiring Special Purpose MPLS Labels |
| |
|
Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines some procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. |
| | Extensions to RSVP-TE for P2MP LSP Egress Local Protection |
| |
|
This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Path (LSP) in a Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. |
| | Problem Statement of SAVI Beyond the First Hop |
| |
|
IETF Source Address Validation Improvements (SAVI) working group is chartered for source address validation within the first hop from the end hosts, i.e. preventing a node from spoofing the IP source address of another node in the same IP link. However, since SAVI requires the edge routers or switches to be upgraded, the deployment of SAVI will need a long time. During this transition period, some source address validation techniques beyond the first hop (SAVI-BF) may be needed to complement SAVI and protect the networks from spoofing based attacks. In this document, we first propose three desired features of the SAVI-BF techniques. Then we analyze the problems of the current SAVI-BF technique, ingress filtering. Finally, we discuss the directions that we can explore to improve SAVI-BF. |
| | A Framework for Semantic IPv6 Prefix |
| |
|
This document describes a framework method that network operations may use their addresses. Network operators, who have large IPv6 address space, may choose to embedded some semantics into IPv6 addresses by assigning additional significance to specific bits within the prefix. By embedded semantics into IPv6 prefixes, the semantics of packets can be inspected easily. Routers and other intermediary devices can easily apply relevant policies as required. Packet-level differentiation can also enable flow-level and user- level differentiation. Consequently, the network operators can accordingly treat network packets differently and efficiently. The management and maintenance of networks can be much simpler. |
| | A Framework for Semantic IPv6 Prefix |
| |
|
This document describes a framework method that network operations may use their addresses. Network operators, who have large IPv6 address space, may choose to embedded some semantics into IPv6 addresses by assigning additional significance to specific bits within the prefix. By embedded semantics into IPv6 prefixes, the semantics of packets can be inspected easily. Routers and other intermediary devices can easily apply relevant policies as required. Packet-level differentiation can also enable flow-level and user- level differentiation. Consequently, the network operators can accordingly treat network packets differently and efficiently. The management and maintenance of networks can be much simpler. |
| | Secure Origin Identification: Problem Statement,Requirements,and Roadmap |
| |
|
Over the past decade, SIP has become a major signaling protocol for voice communications, one which has replaced many traditional telephony deployments. However, interworking SIP with the traditional telephone network has ultimately reduced the security of Caller ID systems. Given the widespread interworking of SIP with the telephone network, the lack of effective standards for identifying the calling party in a SIP session has granted attackers new powers as they impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes or even circumventing multi-factor authentication systems trusted by banks. This document therefore examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult, and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. |
| | Security Extension for OSPFv2 when using Manual Key Management |
| |
|
The current OSPFv2 cryptographic authentication mechanism as defined in the OSPF standards is vulnerable to both inter-session and intra- session replay attacks when its uses manual keying. Additionally, the existing cryptographic authentication schemes do not cover the IP header. This omission can be exploited to carry out various types of attacks. This draft proposes changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when its using manual keys for securing its protocol packets. Additionally, we also describe some changes in the cryptographic hash computation so that we eliminate most attacks that result because OSPFv2 does not protect the IP header. |
| | Session Initiation Protocol (SIP) Recording Metadata |
| |
|
Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. |
| |
|
| |
| | Enhanced Duplicate Address Detection |
| |
| | draft-ietf-6man-enhanced-dad-03.txt |
| | Date: |
24/05/2013 |
| | Authors: |
Rajiv Asati, Hemant Singh, Wes Beebee, Eli Dart, Wesley George, Carlos Pignataro |
| | Working Group: |
IPv6 Maintenance (6man) |
| | Formats: |
txt |
|
Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. |
| | Significance of IPv6 Interface Identifiers |
| |
|
The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no generic meaning and that the identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those bits apply only to interface identifiers that are derived from an IEEE link-layer address. It updates RFC 4291 accordingly. |
| | Ogg Encapsulation for the Opus Audio Codec |
| |
|
This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. Ogg encapsulation provides Opus with a long-term storage format supporting all of the essential features, including metadata, fast and accurate seeking, corruption detection, recapture after errors, low overhead, and the ability to multiplex Opus with other codecs (including video) with minimal buffering. It also provides a live streamable format, capable of delivery over a reliable stream-oriented transport, without requiring all the data, or even the total length of the data, up-front, in a form that is identical to the on-disk storage format. |
| | Protocol for Stage Illumination |
| |
|
This memo describes a protocol that builds upon UDP/IP to transport illumination and control data for stage, architectural and other illumination requirements. It may be understood as a spiritual successor of the traditional DMX (Digital MultipleX) specification series, removing it's limitations and adding flexibility and usability enhancements like auto-discovery and metadata, among other useful features. |
| | OSPFTE extension to support GMPLS for Flex Grid |
| |
|
This document specifies the extension to TELINK LSA of OSPF routing protocol [RFC4203] [3] in support of GMPLS [1] for flex-grid networks [2]. |
| | Candidate Technologies for COMAN |
| |
|
This draft identifies candidate technologies and considerations for the COMAN use cases and requirements. Note Discussion and suggestions for improvement are requested, and should be sent to coman@ietf.org. |
| | Dynamic RP encodings in BGP based MVPNs |
| |
|
PIM Group-to-RP mappings are distributed dynamically using protocols such as BSR or Auto-RP. The BGP-MVPN specification provides for this information to be encapsulated in an I-PMSI or S-PMSI provider tunnel between the PEs in an MVPN environment. Since this is control information, it is desirable to signal this information in BGP between PEs, similar to carrying other customer control state such as C-Multicast routes. This document specifies the mechanisms and procedures to carry bootstrap information via BGP to provide true control and data plane separation. |
| | PCP Considerations for WebRTC Usage |
| |
| | draft-penno-rtcweb-pcp-00.txt |
| | Date: |
24/05/2013 |
| | Authors: |
Reinaldo Penno, Tirumaleswar Reddy, Dan Wing, Mohamed Boucadair |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
This document describes the motivations for WebRTC applications to be PCP-aware and the benefits provided by PCP-capable NATs and Firewalls. |
| | NVGRE Router Alert Option |
| |
|
This proposal describes a new option to achieve a mechanism which alerts NVGRE egress End Point to more closely examine the contents of the packet encapsulated under NVGRE header. This option is useful for case(s) where a given frame encapsulated within a given NVGRE segment responsible for carrying data between two different End Systems contains some control information (e.g OAM information) that may require special handling/processing at NVGRE egress End Point. |
| | VxLAN Router Alert Option |
| |
|
This proposal describes a new option to achieve a mechanism which alerts VxLAN terminating VTEP to more closely examine the contents of the packet encapsulated under VxLAN header. This option is useful for case(s) where a given frame encapsulated within a given VXLAN segment responsible for carrying data between two different End Systems contains some control information (e.g OAM information) that may require special handling/processing by terminating VTEP. |
| | PCP Extension for Third Party Authorization |
| |
|
It is often desirable for an application server to permit a flow across a firewall, as happens today when a firewall includes an Application Layer Gateway (ALG) function. However, an ALG has several weaknesses. This document describes a cryptographic technique for an application server to permit a flow across a firewall. This technique uses OAuth and a new PCP option. |
| | Mapping characters for PRECIS classes |
| |
| | draft-ietf-precis-mappings-02.txt |
| | Date: |
24/05/2013 |
| | Authors: |
Yoshiro Yoneya, Takahiro NEMOTO |
| | Working Group: |
Preparation and Comparison of Internationalized Strings (precis) |
| | Formats: |
txt |
|
The framework for preparation and comparison of internationalized strings ("PRECIS") defines several classes of strings for preparation and comparison. In the framework, case mapping is defined because many protocols handle case-sensitive or case-insensitive string comparison and therefore preparation of the string is mandatory. As described in the mapping for Internationalized Domain Names in Applications (IDNA) and the PRECIS problem statement, mappings for internationalized strings are not limited to case, but also width mapping and mapping of delimiters and other specials can be taken into consideration. This document provides guidelines for authors of protocol profiles of the PRECIS framework and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. The mappings described here are expected to be applied as Addtional mapping in the PRECIS framework. |
| | Framework for Loop-free convergence using oFIB |
| |
| | draft-ietf-rtgwg-ordered-fib-12.txt |
| | Date: |
24/05/2013 |
| | Authors: |
Mike Shand, Stewart Bryant, Stefano Previdi, Clarence Filsfils, Pierre Francois, Olivier Bonaventure |
| | Working Group: |
Routing Area Working Group (rtgwg) |
| | Formats: |
txt xml |
|
This document describes an illustrative framework of a mechanism for use in conjunction with link state routing protocols which prevents the transient loops which would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers. This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast re-route mechanism which converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described. The technology described in this document has been subject to extensive simulation using real network topologies and costs, and pathological convergence behaviour. However the mechanism described in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. |
| | A Framework for IP and MPLS Fast Reroute Using Not-via Addresses |
| |
|
This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics. The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification. The document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. |
| |
|
| |
| | Updates to the IPv6 Multicast Addressing Architecture |
| |
|
This document updates the IPv6 multicast addressing architecture by defining the 17-20 reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306, RFC 4607 and RFC 4291. |
| | GMPLS RSVP-TE Extensions for Lock Instruct and Loopback |
| |
|
This document specifies extensions to RSVP-TE to support lock instruct and loopback mechanism for LSPs. The mechanisms are applicable to technologies which use GMPLS as control plane. |
| | The Accumulated IGP Metric Attribute for BGP |
| |
| | draft-ietf-idr-aigp-10.txt |
| | Date: |
23/05/2013 |
| | Authors: |
Prodosh Mohapatra, Rex Fernando, Eric Rosen, James Uttaro |
| | Working Group: |
Inter-Domain Routing (idr) |
| | Formats: |
txt |
|
Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. |
| | Media Control Channel Framework (CFW) Call Flow Examples |
| |
|
This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. |
| | A TCP Authentication Option Extension for NAT Traversal |
| |
|
This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through network address and/or port translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but does not alter TCP-AO's packet processing or key generation algorithms. |
| | RADIUS Extensions for Port Control Protocol (PCP) |
| |
|
This document specifies a new Remote Authentication Dial In User Service (RADIUS) attribute to carry a Port Control Protocol (PCP) Server Names. This attribute can be configured on a RADIUS server so that the information can be conveyed to Network Access Server (NAS) via RADIUS protocol, and the co-located Dynamic Host Configuration Protocol (DHCP/DHCPv6) server can then populate the information to PCP client. |
| | Prefix Assignment in a Home Network |
| |
|
This memo describes a prefix assignment mechanism for home networks. It is expected that home gateway routers are allocated an IPv6 prefix through DHCPv6 Prefix Delegation (PD) or that a prefix is made available through other means. This prefix needs to be divided among the multiple subnets in a home network. This memo describes a mechanism for such division, or assignment, via OSPFv3. This is an alternative design to also using DHCPv6 PD for the assignment. The memo is input to the working group so that it can make a decision on which type of design to pursue. It is expected that a routing- protocol based assignment uses a minimal amount of prefixes. |
| | Using IEEE802.15.4e TSCH in an LLN context: Overview,Problem Statement and Goals |
| |
|
This document describes the environment, problem statement, and goals for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. The set of goals enumerated in this document form an initial set only. |
| | 6tus Layer Specification |
| |
|
The recently published [IEEE802154e] standard formalizes the concept of link-layer resources in LLNs. Nodes are synchronized and follow a schedule. A time slot in that schedule corresponds to an atomic link-layer resource, and can be allocated to any pair of neighbors in the network. This allows the schedule to be built to tightly match each node's bandwidth, latency and energy constraints, while ensuring collision-free communication. The [IEEE802154e] standard does not, however, present a mechanism to do so, as building and managing the schedule is out of the standard's scope. Routing layers such as the IETF IPv6 Routing Protocol for LLNs (RPL) provide a mechanism to route multipoint-to-point traffic (from devices inside the LLN towards a central control point) and point-to-multipoint traffic (from the central control point to the devices inside the LLN). Network layer overlays cannot be optimized and adapted to take advantage of the cell-based topology created by the underlying TSCH MAC layer as a missing set of functionalities need to be defined. This document describes the 6tus layer and the main commands it provides to upper network layers such as RPL or GMPLS. The set of functionalities includes feedback metrics from cell states so network layers can take routing decisions, TSCH configuration and control procedures, and the support for centralized and decentralized scheduling policies. |
| | Recommended Usages of SHA-512/224,SHA-512/256 |
| |
|
This document provides recommendations on the use of the secure hash functions SHA-512/224 and SHA-512/256 specified in FIPS 180. SHA- 512/224 and SHA-512/256 are SHA-512-based and truncated to match the output size of SHA-224 and SHA-256. On 64-bit platforms, the SHA-512- truncated algorithms provide better performance than their comparably sized SHA-224 and SHA-256 variants. |
| | Dynamic RP encodings in BGP based MVPNs |
| |
|
PIM Group-to-RP mappings are distributed dynamically using protocols such as BSR or Auto-RP. The BGP-MVPN specification provides for this information to be encapsulated in an I-PMSI or S-PMSI provider tunnel between the PEs in an MVPN environment. Since this is control information, it is desirable to signal this information in BGP between PEs, similar to carrying other customer control state such as C-Multicast routes. This document specifies the mechanisms and procedures to carry bootstrap information via BGP to provide true control and data plane separation. |
| | The Network Access Identifier |
| |
|
In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each others users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282 [RFC4282], which addresses issues with international character sets, as well as a number of other corrections to the previous document. |
| | Remote LFA FRR |
| |
|
This draft describes an extension to the basic IP fast re-route mechanism described in RFC5286 that provides additional backup connectivity for link failures when none can be provided by the basic mechanisms. |
| | An Architecture for Media Recording using the Session Initiation Protocol |
| |
|
Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). |
| | Session Initiation Protocol (SIP) Overload Control |
| |
|
Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behaviour of SIP servers involved in overload control, and in addition, it specifies a loss-based overload scheme for SIP. |
| | Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,Version 1 |
| |
|
Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a ADMDs (ADministrative Management Domains) can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. This document obsoletes RFC4408. |
| | TCP Extensions for High Performance |
| |
| | draft-ietf-tcpm-1323bis-14.txt |
| | Date: |
23/05/2013 |
| | Authors: |
David Borman, Robert Braden, Van Jacobson, Richard Scheffenegger |
| | Working Group: |
TCP Maintenance and Minor Extensions (tcpm) |
| | Formats: |
txt xml |
|
This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps. The timestamps are used for two distinct mechanisms, RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). This document updates and obsoletes RFC 1323. |
| | TRILL OAM Framework |
| |
| | draft-ietf-trill-oam-framework-02.txt |
| | Date: |
23/05/2013 |
| | Authors: |
Samer Salam, Tissa Senevirathne, Sam Aldrin, Donald Eastlake |
| | Working Group: |
Transparent Interconnection of Lots of Links (trill) |
| | Formats: |
txt |
|
This document specifies a reference framework for Operations, Administration and Maintenance (OAM) in TRILL networks. The focus of the document is on the fault and performance management aspects of TRILL OAM. |
| | Byte and Packet Congestion Notification |
| |
|
This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, such as random early detection (RED), BLUE, pre-congestion notification (PCN), etc. We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte-mode packet drop variant that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. |
| |
|
| |
| | Sieve Email Filtering: Detecting Duplicate Deliveries |
| |
|
This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplicate message deliveries. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. |
| | rxgk: GSSAPI based security class for RX |
| |
|
rxgk is a security class for the RX RPC protocol. It uses the GSSAPI framework to provide an authentication service that provides authentication, confidentiality and integrity protection for the rxgk security class. This document provides a general description of rxgk and how to integrate it into generic RX applications. Application specific behaviour will be described, as necessary, in future documents. |
| | Miscellaneous additions to CoAP |
| |
|
This short I-D makes a number of partially interrelated proposals how to solve certain problems in the CoRE WG's main protocol, the Constrained Application Protocol (CoAP). The current version has been resubmitted to keep information about these proposals available; the proposals are not all fleshed out at this point in time. |
| | Textual Representation of IPFIX Abstract Data Types |
| |
|
This document defines UTF-8 representations for IPFIX abstract data types, to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. |
| | LISP Based FlowMapping for Scaling NFV |
| |
| | draft-barkai-lisp-nfv-01.txt |
| | Date: |
22/05/2013 |
| | Authors: |
sbarkai@gmail.com, Dino Farinacci, David Meyer, Fabio Maino, Vina Ermagan |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft describes an RFC 6830 Locator ID Separation Protocol (LISP) based distributed flow-mapping-fabric for dynamic scaling of virtualized network functions (NFV). Network functions such as subscriber-management, content-optimization, security and quality of service, are typically delivered using proprietary hardware appliances embedded into the network as turn-key service-nodes or service-blades within routers. Next generation network functions are being implemented as pure software instances running on standard servers - unbundled virtualized components of capacity and functionality. LISP-SDN based flow-mapping, dynamically assembles these components to whole solutions by steering the right traffic in the right sequence to the right virtual function instance. |
| | IPv6 Multicast Address Scopes |
| |
|
This document updates the definitions of IPv6 multicast scopes. |
| | PCP Server Selection |
| |
|
This document specifies the behavior to be followed by the PCP client to contact its PCP server(s) when one or several PCP server names are configured. Multiple names may be configured to a PCP client in some deployment contexts such as multi-homing. This document updates RFC6887. |
| | Multiple Repository Publication Points support in the Resource Public Key Infrastructure (RPKI) |
| |
|
The Resource Public Key Infrastructure (RPKI) depends on Relying Parties (RP) ability to access its Trust Anchors' certificate specified in the different "Trust Anchor Locator (TAL)" files and the Repository Objects located at the Certificate Authorities (CA) repositories hosted in its respective publication point. This document updates [RFC6490] by allowing multiple URI associated to a single public key in a TAL file and introduces the concept of multiple repository publication point operators for every CA in the RPKI. This document provides also recommendation for the RP behavior when analyzing signed objects that include multiple publications points. |
| |
|
| |
| | ALTO Protocol |
| |
| | draft-ietf-alto-protocol-16.txt |
| | Date: |
21/05/2013 |
| | Authors: |
Richard Alimi, Reinaldo Penno, Yang Yang |
| | Working Group: |
Application-Layer Traffic Optimization (alto) |
| | Formats: |
txt |
|
Applications using the Internet already have access to topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at looking glass servers are available and can be practically downloaded to many application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs (henceforth referred as Providers). In other words, what a Provider prefers in terms of traffic optimization -- and a way to distribute it. The Application-Layer Traffic Optimization (ALTO) Service provides network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps. This document describes a protocol implementing the ALTO Service. Although the ALTO Service would primarily be provided by the network service providers (e.g., Internet service providers), content service providers and third parties could also operate an ALTO service. Applications that could use this service are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks. |
| | Home Networking Architecture for IPv6 |
| |
|
This text describes evolving networking technology within increasingly large residential home networks. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. |
| | Assigned BGP extended communities |
| |
|
This document defines an IANA registry in order to assign non- transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide a control over inter-AS community advertisement as, per RFC RFC 4360, they are not transitive across Autonomous System boundaries. For that purpose, this document defines the use of the reserved Autonomous System number 0.65535 in the non-transitive generic four- octet AS specific extended community type. |
| | North-Bound Distribution of Link-State and TE Information using BGP |
| |
|
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). |
| | Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management |
| |
|
This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. This document obsoletes RFC3811 as it addresses the need to support IPv6 extended TunnelID's by defining a new TC- MplsNewExtendedTunnelID which suggests using IPv4 address of the ingress or egress LSR for the tunnel for an IPv6 network. Changes from RFC3811 and the effect of the new TC to other related documents are summarized in Section 4 and 5, respectively. |
| | RADIUS Extensions for Port Set Configuration and Reporting |
| |
|
This document defines new RADIUS attributes that can be used by a device implementing port ranges to communicate with a RADIUS server to configure and/or report TCP/UDP port sets and ICMP identifiers mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as CGN, NAT64, Provider WiFi Gateway, etc. This document does not make any assumption about the deployment context. |
| | A Roadmap for Transmission Control Protocol (TCP) Specification Documents |
| |
|
This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. |
| | NVGRE and VXLAN Encapsulation for L3VPN Extension |
| |
|
This document specifies NVGRE and VXLAN encapsulation for L3VPN Extension. Both NVGRE and VXLAN are originally designed for L2 overlay. The draft proposes the enhancement on both to allow L3 overlay completely decoupled from the L2 overlay in terms of encoding schema and data processing. |
| | PAWS Database Discovery |
| |
|
This document provides a Database Discovery mechanism for PAWS. By this mechanism the master device gets the available WSDBs with which it should communicate as well as the regulatory domain information. The mechanism is based on the LoST protocol . |
| | Advertising MPLS labels in IS-IS |
| |
|
Historically MPLS label distribution was driven by protocols like LDP, RSVP and LBGP. All of those protocols are session oriented. In order to obtain a label binding for a given destination FEC from a given router one needs first to establish an LDP/RSVP/LBGP session with that router. Advertising MPLS labels in IGPs [I-D.gredler-rtgwg-igp-label-advertisement] describes several use cases where utilizing the flooding machinery of link-state protocols for MPLS label distribution allows to obtain the binding without requiring to establish an LDP/RSVP/LBGP session with that router. This document describes the protocol extension to distribute MPLS label bindings using the IS-IS protocol. |
| | Advertising MPLS labels in OSPF |
| |
|
Historically MPLS label distribution was driven by protocols like LDP, RSVP and LBGP. All of those protocols are session oriented. In order to obtain label binding for a given destination FEC from a given router one needs first to establish an LDP/RSVP/LBGP session with that router. Advertising MPLS labels in IGPs [I-D.gredler-rtgwg-igp-label-advertisement] describes several use cases where utilizing the flooding machinery of link-state protocols for MPLS label distribution allows to obtain the binding without requiring to establish an LDP/RSVP/LBGP session with that router. This document describes the protocol extension to distribute MPLS label bindings by the OSPFv2 and OSPFv3 protocol. |
| | A Common Operational Problem in DNS Servers - Failure To Respond. |
| |
|
The DNS is a query / response protocol. Failure to respond to queries causes both immediate operational problems and long term problems with protocol development. This document will identify a number of common classes of queries that some servers fail to respond too. This document will also suggest procedures for TLD and other similar zone operators to apply to reduce / eliminate the problem. |
| | GOST R 34.10-2012: Digital Signature Algorithm |
| |
|
This document is intended to be a source of information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST R 34.10-2012 for digital signature generation and verification. |
| | J-PAKE: Password Authenticated Key Exchange by Juggling |
| |
|
This document specifies a Password Authenticated Key Exchange by Juggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party. |
| | Schnorr Signature: Non-interactive Zero Knowledge Proof for Discrete Logarithm |
| |
|
This document describes the Schnorr signature, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr signature allows one to prove the knowledge of a discrete logarithm without leaking its value. It can serve as a useful building block for many cryptographic protocols to ensure the participants follow the protocol specification honestly. |
| |
|
| |
| | The application/json-merge-patch Media Type |
| |
|
This specification defines the application/json-merge-patch media type and it's intended use with the HTTP PATCH method defined by RFC 5789. |
| | AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) |
| |
|
This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. |
| | RADIUS Option for DHCPv6 Relay Agent |
| |
|
The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. |
| | BGP Custom Decision Process |
| |
|
The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. This document defines a new Extended Community, called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. |
| | Operations Model for Router Keying |
| |
|
Developing an operational and management model for routing protocol security that works across protocols will be critical to the success of routing protocol security efforts. This document discusses issues and begins to consider development of these models. |
| | Analysis of RSVP-TE Security According to KARP Design Guide |
| |
|
This document analyzes Resource reSerVation Protocol-Traffic Engineering (RSVP-TE) according to guidelines set forth in section 4.2 of KARP Design Guidelines (RFC 6518). |
| | Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types |
| |
|
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. |
| | HTTP/2.0 Discussion: Extension Frame Types |
| |
|
This memo describes the structure and use cases for a handful of "extension" frames types for HTTP 2.0. The purpose of this document is to add to the overall discussion around the development of HTTP 2.0 by describing ways in which the framing layer can be leveraged and extended. |
| | PCP Description Option |
| |
|
This document extends Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does so by defining a new DESCRIPTION option. |
| | Port Control Protocol (PCP) Extension for Port Set Allocation |
| |
| | draft-ietf-pcp-port-set-01.txt |
| | Date: |
20/05/2013 |
| | Authors: |
Qiong Sun, Mohamed Boucadair, Senthil Sivakumar, Cathy Zhou, Tina Tsou, Simon Perreault |
| | Working Group: |
Port Control Protocol (pcp) |
| | Formats: |
txt xml |
|
This document defines an extension to PCP allowing clients to manipulate sets of ports as a whole. This is accomplished by a new MAP option: PORT_SET. |
| | Operational Considerations Regarding Reputation Services |
| |
|
The use of reputation systems is has become a common tool in many applications that seek to apply collected intelligence about traffic sources. Often this is done because it is common or even expected operator practice. It is therefore important to be aware of a number of considerations for both operators and consumers of the data. This document includes a collection of the best advice available regarding providers and consumers of reputation data, based on experience to date. Much of this is based on experience with email reputation systems, but the concepts are generally applicable. |
| |
|
| |
| | BFD for Multipoint Networks |
| |
|
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg-bfd@ietf.org. |
| | Summary of Opus listening test results |
| |
|
This document describes and examines listening test results obtained for the Opus codec and how they relate to the requirements. |
| | Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) |
| |
|
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry. |
| | Lightweight Directory Access Protocol (LDAP): Schema for Printer Services |
| |
|
This document defines a schema, object classes and attributes, for Printers and Print Services, for use with directories that support Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). Additional Printer attributes are based on definitions in the Printer MIB v2 (RFC 3805), IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2), IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13), and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14). This document is published by the IETF on behalf of the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group. This document updates RFC 3712. |
| | Analysis of Algorithms For Deriving Port Sets |
| |
|
This memo analyzes some port set definition algorithms used for stateless IPv4 to IPv6 transition technologies. The transition technologies using port set algorithms can be divided into two categories: fully stateless approach and binding approach. Some algorithms can work for both approaches. |
| | Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV) |
| |
|
This specification defines how the HTTP Prefer header can be used by a WebDAV client to request that certain behaviors be employed by a server while constructing a response to a successful request. |
| | A Mechanism for Diameter Overload Control |
| |
|
When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce or stop sending traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages. This document proposes a concrete, application-independent mechanism to address the challenge of communicating load and overload state among Diameter peers, and specifies an algorithm for load abatement to address such overload conditions as they occur. The load abatement algorithm is extensible, allowing for future documents to define additional load abatement approaches. |
| | Enhancing Location Based IP Services |
| |
|
This document describes IP-LOC, a proposed extension to IPv6 header which suggests adding optional geo-location field, in order to enhance existing geo-location based IP service as well as adding new ones. The current method of determining geo-location of IP traffic is through RIR (Regional Internet Registry) database, this information is not very accurate as it depends on how the ISP registers its IP subnets, that is normally done in a country/city format. It also assumes that in the future, GPS capability could be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. QoS, firewall and routing based on geo-location might also be required in the future when mobile routers move from one geo-location to another, which has a different policy. |
| | Security and Reliable Multicast Transport Protocols: Discussions and Guidelines |
| |
|
This document describes general security considerations for Reliable Multicast Transport (RMT) building blocks and protocols. An emphasis is placed on risks that might be resolved in the scope of transport protocol design. However, relevant security issues related to IP Multicast control-plane and other concerns not strictly within the scope of reliable transport protocol design are also discussed. The document also begins an exploration of approaches that could be embraced to mitigate these risks. The purpose of this document is to provide a consolidated security discussion and provide a basis for further discussions and potential resolution of any significant security issues that may exist in the current set of RMT standards. |
| | Session Recording Protocol |
| |
|
This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. |
| | TRILL (Transparent Interconnection of Lots of Links): Fine-Grained Labeling |
| |
| | draft-ietf-trill-fine-labeling-07.txt |
| | Date: |
17/05/2013 |
| | Authors: |
Donald Eastlake, Mingui Zhang, Puneet Agarwal, Radia Perlman, Dinesh Dutt |
| | Working Group: |
Transparent Interconnection of Lots of Links (trill) |
| | Formats: |
txt |
|
The IETF has standardized TRILL (Transparent Interconnection of Lots of Links), a protocol for least cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports labeling of TRILL data with up to 4K IDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine grained labeling, are primarily intended for use in large Data Centers, those with >4K users requiring configurable data isolation from each other. |
| | Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN |
| |
|
This document describes three methods for extending an IPv6 /64 prefix from a User Equipment 3GPP radio interface to a LAN. |
| | Recommendations of Using Unique Local Addresses |
| |
|
This document provides guidance of how to use ULA. It analyzes ULA usage scenarios and recommends use cases where ULA address may be beneficially used. |
| |
|
| |
| | Framework for Telepresence Multi-Streams |
| |
| | draft-ietf-clue-framework-10.txt |
| | Date: |
16/05/2013 |
| | Authors: |
Mark Duckworth, Andrew Pepperell, Stephan Wenger |
| | Working Group: |
ControLling mUltiple streams for tElepresence (clue) |
| | Formats: |
txt |
|
This document offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. |
| | An Encoding Parameter for HTTP Basic Authentication |
| |
|
The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has lead to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for the non-ASCII characters in the ISO-8859-1 character set, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding expectation, using a new authentication scheme parameter. |
| | Analysis of Port Control Protocol (PCP) Failure Scenarios |
| |
|
This document identifies and analyzes several PCP failure scenarios. Identifying these failure scenarios is useful to assess the efficiency of the protocol and also to decide whether new PCP extensions are needed. |
| | Third-Party ALTO Server Discovery (3pdisc) |
| |
| | draft-kist-alto-3pdisc-03.txt |
| | Date: |
16/05/2013 |
| | Authors: |
Sebastian Kiesel, Kilian Krause, Martin Stiemerling |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. This document specifies a procedure for third-party ALTO server discovery, which can be used if the ALTO client is not co-located with the actual resource consumer, but instead embedded in a third party such as a peer-to-peer tracker. Technically, the algorithm specified in this document takes one IP address and a U-NAPTR Service Parameter (i.e., "ALTO:http" or "ALTO:https") as parameters. It performs several DNS lookups (for PTR, SOA, and U-NAPTR resource records) and returns one or more URI(s) of information resources related to that IP address. |
| | File Transfer Protocol HOST Command for Virtual Hosts |
| |
|
The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server. |
| | Internet International Bank Account Number (IIBAN) |
| |
|
An Internet IBAN (IIBAN) identifies an internet-based financial endpoint in a manner that is superset-compatible with the existing European Committee for Banking Standards (ECBS) International Bank Account Number (IBAN) standard [ISO13616] and implementation recommendations [ECBS]. This document obsoletes draft-iiban-00. |
| | Self-published IP Geolocation Data |
| |
|
This document records a format whereby a network operator can publish a mapping of IP address ranges to simplified geolocation information, colloquially termed a geolocation "feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. At least one consumer (Google) has incorporated these ad hoc feeds into a geolocation data pipeline. |
| | Plan to Establish a Wisdom Task Force |
| |
|
This memo calls for the creation of a new governance forum named "Wisdom Task Force" (WisdomTF). The main purpose of the WisdomTF is to facilitate consensus-seeking strategy-oriented discussions regarding governance actions that may be decided by national parliaments. |
| | PCP Authentication Requirements |
| |
|
In an attempt to reach consensus on a PCP authentication mechanism, this document describes requirements for PCP authentication. It is hoped this can serve as the basis for a comparison of PCP authentication mechanisms. |
| | Last Autonomous System (AS) Reservations |
| |
|
This document reserves two Autonomous System numbers (ASNs) at the end of the 16 bit and 32 bit ranges, described in this document as "Last ASNs" and recommends they not be used by operators. |
| | Web Conference Recording Use Case |
| |
|
The current work of SIPREC will soon finish. As its charter defined, SIPREC has covered industries like financial trading floors, contact center and emergency service bureaus. But when talking about products or solutions like data or web conferencing, SIPREC is insufficient to record all aspects of calls with different interactive media channels. This draft tries to show a use case for web conference recording and show how it can work well under SIPREC mechanism. |
| | Definitions of Managed Objects for 6rd |
| |
|
This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing 6rd devices. |
| |
|
| |
| | Reconfigure Triggered by DHCPv6 Relay Agents |
| |
|
This document defines new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. Reconfigure-Reply message is used by the server to acknowledge the receipt of Reconfigure-Request. |
| | A Multiplexing Extension for WebSockets |
| |
|
The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. Please send feedback to the hybi@ietf.org mailing list. |
| | Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes |
| |
|
Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multicast Extensions to Label Distribution Protocol (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. |
| | A YANG Data Model for Interface Management |
| |
|
This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data, state data and counters for the collection of statistics. |
| | Implications of Full-Duplex HTTP |
| |
|
Full-duplex HTTP follows the basic HTTP request-response semantics but also allows the server to send response body to the client at the same time when the client is transmitting request body to the server. Requirements for full-duplex HTTP are under-specified in the existing HTTP specification [RFC2616], and this memo intends to clarify the requirements of full-duplex HTTP on top of the basic HTTP protocol semantics. |
| | TFTP Windowsize Option |
| |
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the early stages of nodes booting from a Local Area Network. TFTP has been always used because it is very simple to implement. However, the choice of a lock-step schema is not the most efficient for use on a LAN. This document describes a TFTP option which allows the client and server to negotiate a windowsize of consecutive blocks to send as an alternative for replacing the single block lock-step schema. The TFTP Option Extension mechanism is described in [2]. |
| | Advertising MPLS labels in IGPs |
| |
|
Historically MPLS label distribution was driven by session oriented protocols. In order to obtain a particular routers label binding for a given destination FEC one needs to have first an established session with that node. This document describes a mechanism to distribute FEC/label mappings through flooding protocols. Flooding protocols publish their objects for an unknown set of receivers, therefore one can efficiently scale label distribution for use cases where the receiver of label information is not directly connected. Application of this technique are found in the field of backup (Bypass, R-LFA) routing, Label switched path stitching, egress protection, explicit routing and egress ASBR link selection. |
| | BGP Extension for MVPN Site-Type Attribute |
| |
|
This document defines a new BGP attribute in BGP based multicast VPN, that allows a MVPN PE router to inform the rest of MVPN PE routers whether it is a sender site/receiver site and there by avoid all other PEs from setting up P-tunnels to the sender site PE. This would reduce control plane states in the network and allow efficient network bandwidth utilization . |
| | PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths |
| |
|
The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes an experiment to provide procedures and extensions to the PCE communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs. |
| |
|
| |
| | Access-Network-Identifier Option in DHCP |
| |
|
This document specifies the format and mechanism that is to be used for encoding access network identifiers in DHCPv4 and DHCPv6 messages by defining new access network identifier options and sub-options. |
| | HTTP Origin-Bound Authentication (HOBA) |
| |
| | draft-ietf-httpauth-hoba-00.txt |
| | Date: |
14/05/2013 |
| | Authors: |
Stephen Farrell, Paul Hoffman, Michael Thomas |
| | Working Group: |
Hypertext Transfer Protocol Authentication (httpauth) |
| | Formats: |
xml txt |
|
HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP authentication method with credentials that are not vulnerable to phishing attacks, and that does not require a server-side password database. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords with all the negative attributes that come with password-based systems. HOBA can be integrated with account management and other applications running over HTTP and supports portability, so a user can associate more than one device or origin-bound key with the same service. We also describe a way in which the HOBA design can be used from a Javascript web client. When deployed, HOBA will be a drop-in replacement for password-based HTTP authentication or JavaScript authentication. |
| | Inter-Area P2MP Segmented LSPs |
| |
|
This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast, or global table multicast over MPLS. |
| | The PKCS#11 URI Scheme |
| |
|
This memo specifies a PKCS#11 Uniform Resource Identifier (URI) Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, for identifying PKCS#11 tokens themselves, or for identifying PKCS#11 libraries. The URI is based on how PKCS#11 objects, tokens, and libraries are identified in the PKCS#11 Cryptographic Token Interface Standard. |
| | HTTP Session Management |
| |
|
The HTTP Session Management Mechanism provides a mean of securely establishing a persistent authentication session between a HTTP client and server that does not rely on the presentation of a confidential bearer token. The Session Management Mechanism is intended to provide a replacement for the existing HTTP State Management Mechanism (Cookies) for this purpose. This document defines the HTTP Accept-Session, Set-Session and Session headers and specifies their use to establish symmetric authentication keys and their use to authenticate and verify specific parts of an HTTP message. Other means by which keys used to authenticate the messages are established are outside the scope of this document. |
| | IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization |
| |
|
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients. The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients. The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes. This document defines an extension to IMAP (RFC 3501). |
| | Definitions of Managed Objects for MAP-E |
| |
|
This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for MAP encapsulation mode. |
| |
|
| |
| | Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks |
| |
| | draft-ietf-ccamp-rwa-info-18.txt |
| | Date: |
13/05/2013 |
| | Authors: |
Young Lee, Greg Bernstein, Dan Li, Wataru Imajuku |
| | Working Group: |
Common Control and Measurement Plane (ccamp) |
| | Formats: |
txt |
|
This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. |
| | Issues with multiple stateful DHCPv6 options |
| |
|
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in [RFC6204] has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. |
| | Diameter Network Access Server Application |
| |
|
This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. |
| | SAML Enhanced Client SASL and GSS-API Mechanisms |
| |
|
Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. |
| | Seamless MPLS Architecture |
| |
| | draft-ietf-mpls-seamless-mpls-03.txt |
| | Date: |
13/05/2013 |
| | Authors: |
Nicolai Leymann, Bruno Decraene, Clarence Filsfils, Maciek Konstantynowicz, Dirk Steinberg |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
| | Formats: |
xml txt |
|
This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. |
| | LDP Extensions for Multi Topology Routing |
| |
|
Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGP protocols. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document updates RFC4379. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. |
| | LDP Downstream-on-Demand in Seamless MPLS |
| |
| | draft-ietf-mpls-ldp-dod-08.txt |
| | Date: |
13/05/2013 |
| | Authors: |
Thomas Beckhaus, Bruno Decraene, Kishore Tiruveedhula, Maciek Konstantynowicz, Luca Martini |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
| | Formats: |
xml txt |
|
Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. |
| | ECC Brainpool Curves for Transport Layer Security (TLS) |
| |
|
This document specifies the use of several ECC Brainpool elliptic curves for authentication and key exchange in the Transport Layer Security (TLS) protocol. |
| | AODV Extensions for MANET Clustering |
| |
|
This document describes an extention on AODV [1] so that clustering of MANET nodes can be allowed for the improvement of MANET scalability. MANET clustering requires some MANET nodes to become Cluster Heads (CHs) and each non-CH MANET nodes to belong to any one appropriate cluster which is represented by a CH node.In this draft, AODV control messages are extended for MANET clustering. |
| | Architecture for MANET Clustering |
| |
|
This document describes the architecture for clustering in the MANET which can be an efficient communication structure for the case when MANET nodes have the tendency of forming groups. In this type of MANET, each group of nodes forms a cluster which is represented by a cluster head. In this draft, we define the terminology for the MANET clustering and the related communication procedure. |
| | Extended Administrative Groups in MPLS-TE |
| |
|
This document provides additional administrative groups (sometimes referred to as "link colors") to the IGP extensions for MPLS-TE. |
| | TMCH functional specifications |
| |
|
This document describes the requirements, the architecture and the interfaces between the Trademark Clearing House (TMCH) and Domain Name Registries as well as between the TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods. |
| | Traversal Using Relays around NAT (TURN) Extensions for Websocket Allocations |
| |
|
This document defines an extension to TURN that allows it to run over a Websocket [RFC6455] channel. This will allow a client in a restrictive network to exchange and relay media or data over the websocket. |
| | Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks |
| |
|
This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature. This document updates [RFC5820]. |
| | Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP) |
| |
|
Peer-to-Peer(P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes the development of Peer to Peer Streaming Protocol(PPSP) including the tracker and peer protocol, and discusses the scope, requirements and use cases of PPSP. |
| | Applicability Statement: The use of the RPL protocol set in Home Automation and Building Control |
| |
|
The purpose of this document is to provide guidance in the selection and use of RPL protocols to implement the features required in building and home environments. |
| | Operational management of Loop Free Alternates |
| |
|
Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. |
| |
|
| |
| | IRR & Routing Policy Configuration Considerations |
| |
|
The purpose of this document is to catalog past issues influencing the efficacy of Internet Routing Registries (IRR) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day. |
| | Route Leaks & MITM Attacks Against BGPSEC |
| |
|
This document describes a very simple attack vector that illustrates how RPKI-enabled BGPSEC machinery as currently defined can be easily circumvented in order to launch a Man In The Middle (MITM) attack via BGP. It is meant to serve as input to the IETF's Secure Inter-Domain Routing working group during routing security requirements discussions and subsequent specification. |
| | Disabling IPoMPLS and P2P PW LDP Application's State Advertisement |
| |
|
Currently, no LDP capability is exchanged for LDP applications like IP Label Switching and L2VPN P2P PW signaling. When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like mLDP or ICCP. This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications. This, in turn, disables the advertisement of corresponding application state, which would have otherwise be advertised by default, over the established LDP session. |
| | Using the NETCONF Protocol over Transport Layer Security (TLS) |
| |
|
The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure the exchange of NETCONF messages. This document obsoletes RFC 5539. |
| | Licklider Transmission Protocol (LTP),Compressed Bundle Header Encoding (CBHE),and Bundle Protocol IANA Registries |
| |
|
The DTNRG research group has defined the experimental Licklider Transmission Protocol (LTP) [RFC5326] and the Compressed Bundle Header Encoding (CBHE) [RFC6260] mechanism for the 'ipn' URI scheme. Finally, RFC5050 [RFC5050] defines values for the Bundle Administrative Record Type. All of these describe fields that are subject to a registry. For the purpose of its research work, the group has created ad-hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official custody. This document describes the actions needed to be executed by IANA. |
| | Conference Focus Indicating CCMP Support |
| |
|
The Centralized Conferencing Manipulation Protocol document defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the XCON conference event package RFC 4575 [RFC4575] and take advantage of CCMP operations on the conference. This document describes a few options to address the above limitation with the pros and cons for each approach, and recommends two to be used depending on the need of the UA. The first approach uses the Call-Info header and as a result this document updates RFC 3261 [RFC3261]. The second approach defines a new value for the 'purpose' parameter in the 'service-uris' element in the SIP conferencing event package, and as a result this document updates RFC 4575 [RFC4575]. |
| | Stateful PCE extensions for MPLS-TE LSPs |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to provide stateful control. This document describes the objects and TLVs to be used with these PCEP extensions to control Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via a stateful PCE. |
| | The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) |
| |
|
The WebSocket protocol enables two-way real-time communication between clients and servers. This document specifies a new WebSocket sub-protocol as a reliable transport mechanism between MSRP (Message Session Relay Protocol) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFC 4975 and RFC 4976. |
| | Power Based Topologies in OSPF using LDP for label exchanges |
| |
|
In this specification OSPF shortest path first computation is done based on power ratios (consumed-power to available-bandwidth OR available-bandwidth to available-bandwidth) assigned to links and nodes such as Broadcast-Multi-Access networks that form part of the topology in an area. When MPLS is deployed in the area (be it the backbone or non-backbone area) LDP can be used to distribute a disjoint set of labels for the power based topology. Flows some or all of those that traverse the area can then be mapped either to the regular shortest-path tree or the power based shortest-path tree. This document specifies the proposal to construct and maintain such a tree called the power based SPT. |
| | The WebRTC Data Channel as a Transport for the Message Session Relay Protocol (MSRP) |
| |
|
The WebRTC Data Channel enables two-way real-time communication between browsers. This document updates normatively updates RFC 4975 to add support for WebRTC Data Channel as a transport for MSRP (Message Session Relay Protocol). This will enable secure, low- latency, structured peer-to-peer messaging between WebRTC end-points. |
| | Netconf surprises |
| |
|
This document identifies some aspects of Netconf that may come as a suprise to those familiar with the use of SNMP for device management. |
| | Disable "Proxy ARP for Everything" on IPv4 link-local in the presence of IPv6 global address |
| |
|
rfc3927 defines the behavior "Proxy ARP for Everything" in case the only address present on the host is IPv4 link-local. However, it does not specify anything about the presence or absence of IPv6 global addressing. This results in the hosts assuming it has both IPv4 and IPv6 connectivity in the scenario where the host itself is dualstack-enabled, but the network supplies only IPv6 configuration information. Some implementations in this case may decide to use IPv4, which results in long connection delays. This document proposes to avoid the "Proxy ARP for Everything" behavior if the host has been assigned an IPv6 address. |
| | Address Autoconfiguration for RPL |
| |
|
This document presents a straightforward address autoconfiguration mechanism for RPL over low power and lossy networks (LLN). A solution is proposed to add the capability of reusable address allocation. In this solution, nodes are assigned with unique IPv6 addresses according to their positions in the network. The amount of routing entries kept at each node is reduced. Also, this document introduces a dynamic adjustment strategy for adapting to uneven distribution of node density. |
| | Problem Statement: Overlays for Network Virtualization |
| |
|
This document describes issues associated with providing multi- tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach. A key multi-tenancy requirement is traffic isolation, so that one tenant's traffic is not visible to any other tenant. Another requirement is address space isolation, so that different tenants can use the same address space within different virtual networks. Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway). Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network, and maintaining that association as the virtual machine is activated, migrated and/or deactivated. Use of an overlay-based approach enables scalable deployment on large network infrastructures. |
| | PCEP Extensions for Stateful PCE |
| |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. |
| |
|
| |
| | Port Management To Reduce Logging In Large-Scale NATs |
| |
|
Various IPv6 transition strategies require the introduction of large- scale NATs (e.g. AFTR, NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete. There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address. One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs. This document suggests a way to achieve dynamic port sharing while keeping log volumes low. |
| | The SignPuddle Standard for SignWriting Text |
| |
|
For concreteness, because the universal character set is not yet universal, and because an international standard for the internet community should be documented and stable, this I-D has been released with the intention of producing an RFC to document the character use and naming conventions of the SignWriting community on the Internet. The SignWriting Script is an international standard for writing sign languages by hand or with computers. From education to research, from entertainment to religion, SignWriting has proven useful because people are using it to write signed languages. The SignWriting Script has two major families: Block Printing for the reader and Handwriting for the writer. The script encoding model presented in this document evolved from the Block Printing half of the SignWriting Script. The SignWriting Text encoding model encompasses the Block Printing family of the SignWriting Script. The plain text model for the mathematical names has been stable since January 12th, 2012. The visual image can be SVG generated on the server or created with an experimental TrueType Font. The coded character sets and character encoding forms are documented with regular expressions. The ad hoc graphemes of informal SignWriting were first created in 1974. Ad hoc graphemes are still used in the handwriting family. The standardized symbols of computerized Block Printing text began in 1986. After several generations of writers and standardized symbolsets, the ISWA 2010 has been optimized and refined as a 16-bit coded character set with several isomorphic encodings based on an ordered hierarchy with 6 degrees of significance. The International SignWriting Alphabet 2010 is a mathematical symbolset that has been stable since its initial release on May 11th, 2010. The SignPuddle Standard for SignWriting Text is an open and freely available encoding model for sign language as text. The licenses include the Open Font License for the fonts, Creative Commons by-sa (Attribution, Share Alike) for the documentation, and the GPL for the software implementation. The technological infrastructure continues to expand and should be fully realized by the time this I-D has become an RFC. SignPuddle Online contains almost 1 million examples of 2-dimensional signs written by the internet community. Each logogram has a mathematical name which describes the freeform placement of the symbols. These strings are the written record of the sign. This standard and emerging infrastructure are used for the sign language Wikipedia project on Wikimedia Labs. This standard is being integrated with the SignTyp linguistic coding system developed by Rachel Channon through an NSF grant. This standard was the origin for the alternate Unicode proposals. For Unicode, the current use of the Private Use Area font characters is documented. The state of the TrueType Font is explained. A character proposal for plane 1 is included that is isomorphic with the characters that are currently used by the community. Three appendices discuss additional topics to the standard. The first discusses the Modern SignWriting theory and example document, stable since January 12, 2012. The second discusses the founding principles of Cartesian SignWriting: a script encoding model for SignWriting Block Printing. The third discusses a common framework for written sign language grammar. This memo concretely defines a conceptual character encoding map for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. |
| | Considerations with WebRTC in Mobile Networks |
| |
|
This document discusses some of the issues with WebRTC applications in Mobile Networks. |
| | IPv6 Email Authentication |
| |
|
IPv6 facilitates network routing over an incredibly vast address space, but abuse mitigation resolving to underlying structures of routes or blocks of prefixes would be highly disruptive due to collateral effects. Use of domains minimizes unintended coincidental blocking while offering the consolidation necessary to facilitate connection management. Currently, email lacks conventions ensuring SMTP clients can be identified by an authenticated domain. DKIM is independent of intended recipients and domains accountable for having sent email. SPF normally requires several text based responses imposing high overhead to query various locations. These locations can be constructed by email-address local-part macros which can flood caches or leverage DNS name compression to further increase network DDoS amplifications when receivers' attempt to verify message sources which may then only offer authorization, not authentication of accountable domains. Most email abuse, including what might be imposed by SPF, is prevented with comprehensive mapping of the address space, but such mapping is impractical with IPv6. An effective authenticated domain name alternative is needed to provide a basis for assessing and reacting to abusive behavior. For most high scale protocols, this involves cryptography. |
| | Supporting Authentication Trailer for OSPFv3 |
| |
|
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. This document obsoletes RFC 6506. |
| | CAPWAP Extension for 802.11n and Power/channel Reconfiguration |
| |
|
CAPWAP binding for 802.11 is specified by RFC5416 and it was based on IEEE 802-11.2007 standard. After RFC5416 was published in 2009, there was several new amendent of 802.11 has been published. 802.11n is one of those amendent and it has been widely used in real deployment. This document extends the CAPWAP binding for 802.11 to support 802.11n. |
| | Policy Qualifiers in RPKI Certificates |
| |
|
This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of RPKI resource certificates. |
| | Public IPv4 over IPv6 Access Network |
| |
|
When the service provider networks are upgraded to IPv6, end users will continue to demand IPv4 connectivity. This document describes a mechanism for hosts or customer networks in IPv6 access network to build bidirectional IPv4 communication with the IPv4 Internet. The mechanism follows the hub and spokes softwire model, and uses IPv4- over-IPv6 tunnel as basic method to traverse IPv6 network. The bi- directionality of this IPv4 communication is achieved by explicitly allocating public IPv4 addresses to end users, as well as maintaining IPv4-IPv6 address binding on the border relay. This mechanism features the allocation of full IPv4 address over IPv6 network, and has been used in production for high-end IPv4 users, IPv6 transition of ICPs, etc. |
| |
|
| |
| | RTP Clock Source Signalling |
| |
| | draft-ietf-avtcore-clksrc-04.txt |
| | Date: |
08/05/2013 |
| | Authors: |
Aidan Williams, Kevin Gross, Ray van Brandenburg, Hans Stokking |
| | Working Group: |
Audio/Video Transport Core Maintenance (avtcore) |
| | Formats: |
txt xml |
|
NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies SDP signalling identifying timestamp reference clock sources and SDP signalling identifying the media clock sources in a multimedia session. |
| | Syslog Format for NAT Logging |
| |
|
With the wide deployment of Carrier Grade NAT (CGN) devices, the logging of NAT-related events has become very important for legal purposes. The logs may be required to identify a host that was used to launch malicious attacks or engage in illegal behaviour, and/or may be required for accounting purposes. This document identifies the events that need to be logged and the parameters that are required in the logs depending on the context in which the NAT is being used. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 5101). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging. |
| | ForCES Intra-NE High Availability |
| |
| | draft-ietf-forces-ceha-07.txt |
| | Date: |
08/05/2013 |
| | Authors: |
Kentaro Ogawa, Weiming Wang, Evangelos Haleplidis, Jamal Hadi Salim |
| | Working Group: |
Forwarding and Control Element Separation (forces) |
| | Formats: |
xml txt |
|
This document discusses Control Element High Availability within a ForCES Network Element. |
| | MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) |
| |
| | draft-ietf-mpls-tp-te-mib-06.txt |
| | Date: |
08/05/2013 |
| | Authors: |
Venkatesan Mahalingam, Kannan Sampath, Sam Aldrin, Thomas Nadeau |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
| | Formats: |
txt |
|
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 of Tunnels, Identifiers, Label Switch Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). |
| | Network File System (NFS) Version 4 Protocol |
| |
|
The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion XDR description document, RFCNFSv4XDR, obsoletes RFC 3530 as the definition of the NFS version 4 protocol. |
| | Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description |
| |
|
The Network File System (NFS) version 4 is a distributed filesystem protocol which owes its heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access, while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. RFC3530bis formally obsoleting RFC 3530. This document, together with RFC3530bis replaces RFC 3530 as the definition of the NFS version 4 protocol. |
| | Advanced Groupware Access Protocol |
| |
|
The Advanced Groupware Access Protocol, (AGAP) allows a client to access and store electronic mail messages, contacts, events, files, and configurations on a server. The electronic mail messages can be grouped in folders. AGAP also provides the capability for an offline client to resynchronize with the server. AGAP does not specify a means of posting electronic mail messages; this function is handled by a mail transfer protocol such as SMTP [RFC2821] . It also does not specify a means for exchanging messages with contacts that are reported as being online; this function is handled by an instant messaging protocol such as XMPP [RFC3921] . AGAP includes the following operations for electronic mail messages: creating, deleting, renaming, moving and coping mail folders; checking for new messages; permanently removing messages; moving and coping messages between folders; fetching information about a message; setting and clearing tags for messages; searching in messages; retrieving only a part of a message; marking messages as SPAM; deleting attachments from a message. AGAP includes the following operations to manipulate the contacts: creating, deleting, moving, coping, tagging, and searching contacts; checking if a contact is online; fetching information about a contact. AGAP includes the following operations related to the use of the events: creating, deleting, moving, coping and tagging events in calendar; fetching events details; searching for events. All entries are read and written in format XML encoded UTF-8 [RFC3629] and each entry is identified by a unique alphanumeric identifier. AGAP is designed to support access only to a single server per connection. It is also designed to balance the volume of text exchanged between the server and clients and its readability by humans for debugging. |
| | VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks |
| |
| | draft-mahalingam-dutt-dcops-vxlan-04.txt |
| | Date: |
08/05/2013 |
| | Authors: |
Mallik Mahalingam, Dinesh Dutt, Kenneth Duda, Puneet Agarwal, Lawrence Kreeger, T. Sridhar, Mike Bursell, Chris Wright |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in cloud service provider and enterprise data center networks. |
| | Home Documents for HTTP APIs |
| |
|
This document proposes a "home document" format for non-browser HTTP clients. Note to Readers This draft should be discussed on the apps-discuss mailing list; see [apps-discuss]. |
| | Indoor Signal Position Conveyance |
| |
|
Location Information Servers rely on signal surveys to create a signal map allowing for subsequent device location determination. This document describes a method by which a Survey Device is able to provide indoor location related measurement data to a LIS for positioning purposes. Location related measurement information comprises observations concerning properties related to the position of a Survey Device and the radio, electromagnetic, and other observable environmental measures as perceived by the Survey Device. These measurements could be data about Wi-Fi signals, Bluetooth signals, barometric pressure, or any other environmental measurement which could sent to a LIS for subsequent processing to help determine the location of devices that later enter the venue. A basic set of location-related measurements, data rights disclosure and location types are defined. |
| | Username Interoperability |
| |
|
Various Internet protocols have defined constructs for usernames. This document describes a subset of characters to allow in usernames for maximal interoperability across Internet protocols. The subset might prove useful in cases where a provider offers multiple services using the same underlying identifier. |
| | Hybrid-MAC Model for CAPWAP |
| |
|
The CAPWAP protocol supports two modes of operation: Split and Local MAC (medium access control), which has been described in [RFC5415].There are many functions in IEEE 802l.11 MAC layer that have not yet been clearly defined whether they belong to either the WTP (Wireless Termination Points) or the AC (Access Controller)in the Split and Local modes. Because different vendors have their own definition of these two models, depending upon the vendor many MAC layer functions continue to be mapped differently to either the WTP or AC. If there is no clear definition of split MAC and local MAC, then operators will not only need to perform vendor specific configurations in their network but will continue to experience difficulty in interoperating WTPs and ACs from different vendors. |
| | Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks |
| |
|
Demands on networking infrastructure are growing exponentially; the drivers are bandwidth hungry rich media applications, inter-data center communications, etc. In this context, it is important to optimally use the bandwidth in wired networks that extensively use LAG/ECMP techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. |
| |
|
| |
| | Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution |
| |
|
This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP control protocol (RTCP), do not mandate a single media security mechanism. Guidelines for designers and reviewers of future RTP extensions are provided, to ensure that appropriate security mechanisms are mandated, and that any such mechanisms are specified in a manner that conforms with the RTP architecture. |
| | IMAP Access to IETF Email List Archives |
| |
|
The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists. Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching, and it is intended as input to a later activity for the design and development of such a service. |
| | Temporal and hitless path segment monitoring |
| |
|
The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport and complement converged packet network deployments. Among the most attractive features of MPLS-TP are OAM functions, which enable network operators or service providers to provide various maintenance characteristics, such as fault location, survivability, performance monitoring, and preliminary or in-service measurements. One of the most important mechanisms which is common for transport network operation is fault location. A segment monitoring function of a transport path is effective in terms of extension of the maintenance work and indispensable particularly when the OAM function is effective only between end points. However, the current approach defined for MPLS-TP for the segment monitoring (SPME) has some fatal drawbacks. This document elaborates on the problem statement for the Sub-path Maintenance Elements (SPMEs) which provides monitoring of a portion of a set of transport paths (LSPs or MS-PWs). Based on the problems, this document specifies new requirements to consider a new improved mechanism of hitless transport path segment monitoring. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. |
| | Proxy MPLS Echo Request |
| |
|
This document defines a means of remotely initiating Multiprotocol Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to leaf/ root tracing. |
| | Diverse Path Implementation Report |
| |
|
This document provides an implementation report for Diverse Path as defined in RFC6774. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. |
| | Depth-First Forwarding in Unreliable Networks (DFF) |
| |
| | draft-cardenas-dff-14.txt |
| | Date: |
07/05/2013 |
| | Authors: |
Ulrich Herberg, Alvaro Cardenas, Tadashige Iwao, Michael Dow, Sandra Cespedes |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
This document specifies the "Depth-First Forwarding" (DFF) protocol for IPv6 networks, a data forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane, but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC2460) and in addition also for LoWPAN "mesh-under" networks (as specified in RFC4944). The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the next hop or not. It is applicable for networks with little traffic, and is used for unicast transmissions only. |
| | URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol |
| |
|
This document is the specification of the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol. |
| | A General Framework of Source Address Validation and Traceback for IPv4/IPv6 Transition Scenarios |
| |
|
IP spoofing always is bothering us along with the Internet invention. With the rapid development of IPv6 next generation Internet, this issue is more prominent. Though many studies have made their contributions to the prevention of IP-spoofing, the most excellent one is the SAVI (Source Address Validation Improvement) proposal advocated by IETF, since it can prevent IP-spoofing from happening by automatically binding the key properties of hosts in layer2 access subnet. Nevertheless, till now, SAVI only focuses on the IPv6 stack and simple network access scenarios. To the best of our knowledge, there is no solution even has paid attention to IPv4/IPv6 transition scenarios. Given the fact that IPv4/IPv6 transition will continue to be adopted for a long period of time, this issue is becoming increasingly urgent. However, since transition schemes are plenty and diverse, hardly can an ordinary solution satisfy all the requirements of various transition scenarios. In this document, we present an improved general SAVI-based framework of IP source address validation and traceback for IPv4/IPv6 transition scenarios. To achieve this goal, we extract essential and mutual properties from these transition schemes, and create sub-solutions for each property. Naturally, if one transition scheme is proposed by combining some properties, the corresponding sub-solutions would be included into its IP source address validation and traceback solution. Therefore, the advantage of this framework is its capability to adapt to all the transition schemes. |
| | SAVI Requirements and Solutions for ISP IPv6 Access Network |
| |
|
Internet is always confronted with many security threats based on IP address spoofing which can enable impersonation and malicious traffic redirection. Unfortunately, the Internet architecture fails to provide the defense mechanism. Source Address Validation Improvement (SAVI) was developed to prevent IP source address spoofing. Especially, the mechanism is essential for ISPs. However, due to the diversity of address assignment methods, SAVI solution is also different accordingly. This document describes five scenarios of ISPs'IPv6 access network, and moreover, states its SAVI requirements and tentative solutions accordingly. |
| | Redundant BFD sessions |
| |
|
This document defines a second or "shadow" BFD session to an existing "primary" BFD session, providing resiliency against BFD failures that are not legitimate. Scenarios will be discussed on how presence of a shadow BFD session will be beneficial in the context of high availability. |
| | TRILL OAM MIB |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines the IETF TRILL (Transparent Interconnection of Lots of Links) OAM objects. |
| | An Approach for Adding RTCWEB Media Streams without Glare |
| |
|
One of the ongoing challenges in dealing with the massive number of streams that RTCWEB implementations may wish to instantiate and manipulate is the ability to add and remove streams in a way that avoids the condition known as "glare." This document describes a non-normative set of behaviors that RTCWEB implementations can implement to completely avoid inducing a glare condition. |
| | Using SDP with Large Numbers of Media Flows |
| |
|
A recurrent theme in WebRTC has been the need to handle very large numbers of media flows. Unfortunately, naive uses of SDP do not handle this case particularly well. This document describes a modest set of extensions to SDP which allow it to cleanly handle arbitrary numbers of flows while still retaining a large degree of backward compatibility with existing and non-RTCWEB endpoints. |
| |
|
| |
| | Packet loss resiliency for Router Solicitations |
| |
|
When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these router solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations. Furthermore, on some links, unsolicited multicast Router Advertisements are never sent and the mechanism in this document is intended to work even in such scenarios. |
| | Options for Securing RTP Sessions |
| |
|
The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity and source authentication of RTP/RTCP packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP, and gives guidance for developers on how to choose the appropriate security mechanism. |
| | General Network Element Constraint Encoding for GMPLS Controlled Networks |
| |
|
Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies. In some of these technologies network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. |
| | An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) |
| |
|
This document specifies an updated Overlay Routable Cryptographic Hash Identifiers format that obsoletes the earlier format defined in [RFC4843]. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite of cryptographic algorithms in use. |
| | Linear Protection Switching in MPLS-TP |
| |
|
This document specifies a linear protection switching mechanism for MPLS-TP. This mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by MPLS-TP data plane, and can work without any control plane. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
| | Using the International Mobile station Equipment Identity(IMEI)URN as an Instance ID |
| |
|
This specification defines how the Uniform Resource Name namespace reserved for the GSMA (GSM Association) identities and its sub- namespace for the IMEI (International Mobile station Equipment Identity) can be used as an instance-id as specified in RFC 5626 [1] and also as used by RFC 5627 [2]. Its purpose is to fulfil the requirements in RFC 5626 [1] that state "If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior." |
| | Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP) |
| |
|
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning of Internationalized Domain Names (IDN) stored in a shared central repository. This mapping extends the EPP domain name mapping to provide additional features required to implement registrations of domain names in characters sets other than ASCII. |
| | Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers |
| |
|
This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes that can be used to provision the configuration values needed by the resolution mechanism defined in [RFC5928]. |
| | ENUM Service Registration for acct URI |
| |
|
This document registers a Telephone Number Mapping (ENUM) service for 'acct:' URIs (Uniform Resource Identifiers). |
| | Session Initiation Protocol Instance ID usage by the Open Mobile Alliance Push-to-talk over Cellular |
| |
|
This document describes how SIP Instance ID as defined in RFC 5626 [1] is used by the Open Mobile Alliance (OMA), for Push-to-talk over Cellular (PoC) and addresses security concerns with use of the SIP instance ID in non-register requests. |
| | Explicit RPF Vector |
| |
|
This document describes a use of the Reverse Path Forwarding (RPF) Vector TLV as defined in [RPC 5496] to build multicast trees via an explicitly configured path sent in the PIM join. |
| | A Uniform Resource Name Namespace for the GSM Association (GSMA) and the International Mobile station Equipment Identity (IMEI) |
| |
| | draft-montemurro-gsma-imei-urn-14.txt |
| | Date: |
06/05/2013 |
| | Authors: |
Michael Montemurro, Andrew Allen, David McDonald, Paul Gosden |
| | Working Group: |
Real-time Applications and Infrastructure Area (rai) |
| | Formats: |
txt |
|
This specification defines a Uniform Resource Name namespace for the GSMA (GSM Association)and a sub-namespace for the IMEI (International Mobile station Equipment Identity), and associated parameter for the IMEISV (International Mobile station Equipment Identity and Software Version number). The IMEI is 15 decimal digits long and the IMEISV is 16 decimal digits long and both are encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV were introduced as part of the specification for Global System for Mobile communications(GSM) and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, the Universal Mobile Telecommunications System (UMTS) and 3GPP LTE (Long Term Evolution). The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA. |
| | SAVI Solution for DHCP |
| |
| | draft-ietf-savi-dhcp-16.txt |
| | Date: |
06/05/2013 |
| | Authors: |
Jun Bi, Jianping Wu, Guang Yao, Fred Baker |
| | Working Group: |
Source Address Validation Improvements (savi) |
| | Formats: |
txt |
|
This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI (Source Address Validation Improvements) device. The bindings set up by this procedure can be used to filter out packets with forged source IP address in DHCP scenario. This mechanism is proposed as a complement to ingress filtering to provide finer-grained source IP address validation. |
| | SAVI for Mixed Address Assignment Methods Scenario |
| |
| | draft-ietf-savi-mix-04.txt |
| | Date: |
06/05/2013 |
| | Authors: |
Jun Bi, Guang Yao, Joel Halpern, Eric Levy-Abegnoli |
| | Working Group: |
Source Address Validation Improvements (savi) |
| | Formats: |
txt |
|
This document reviews how multiple address discovery methods can coexist in a single SAVI device and collisions are resolved when the same binding entry is discovered by two or more methods. |
| |
|
| |
| | Internet Calendar Scheduling Protocol (iSchedule) |
| |
|
This document defines the Internet Calendar Scheduling Protocol (iSchedule), which is a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to the Hypertext Transfer Protocol (HTTP) to enable interoperability between calendaring and scheduling systems over the Internet. |
| | Virtual Enterprise Traversal (VET) |
| |
|
Enterprise networks connect hosts and routers over various link types, and often also connect to the global Internet either directly or via a provider network. Enterprise network nodes require a means to automatically provision addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office / Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in dynamic enterprise networks. |
| | URI Fragment Identifiers for the text/csv Media Type |
| |
|
This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity, identified by row, column, or cell. Fragment identification can use single items, or ranges. Note to Readers This draft should be discussed on the apps-discuss mailing list [11]. Online access to all versions and files is available on github [12]. |
| | The Interior Routing Overlay Network (IRON) |
| |
|
Since large-scale Internetworks such as the public Internet must continue to support escalating growth due to increasing demand, it is clear that Autonomous Systems (ASes) must avoid injecting excessive de-aggregated prefixes into the interdomain routing system and instead mitigate de-aggregation internally. This document describes an Interior Routing Overlay Network (IRON) architecture that supports sustainable growth within AS-interior routing domains while requiring no changes to end systems and no changes to the exterior routing system. In addition to routing scaling, IRON further addresses other important issues including mobility management, mobile networks, multihoming, traffic engineering, NAT traversal and security. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. |
| | OSPF Topology-Transparent Zone |
| |
| | draft-chen-ospf-ttz-05.txt |
| | Date: |
03/05/2013 |
| | Authors: |
Huaimo Chen, Renwei Li, Gregory Cauchie, So Ning, Lei Liu, Alvaro Retana |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document presents a topology-transparent zone in a domain. A topology-transparent zone comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. The information about the links and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a link down inside the zone is not seen by any router outside of the zone. |
| | Applicability of OSPF Topology-Transparent Zone |
| |
| | draft-chen-ospf-ttz-app-03.txt |
| | Date: |
03/05/2013 |
| | Authors: |
Huaimo Chen, Renwei Li, Gregory Cauchie, So Ning, Lei Liu |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document discusses the applicability of "OSPF Topology- Transparent Zone". It briefs the protocol and its operations first, and then illustrates the application scenarios of OSPF Topology- Transparent Zone. In addition, guidelines for deployment are presented and limitations of the protocol are indicated. This document is intended for accompanying "OSPF Topology-Transparent Zone" to the Internet standards track. |
| | I-PAKE: Identity-Based Password Authenticated Key Exchange |
| |
|
Although password authentication is the most widespread user authentication method today, cryptographic protocols for mutual authentication and key agreement, i.e., password authenticated key exchange (PAKE), in particular authenticated key exchange (AKE) based on a password only, are not actively used in the real world. This document introduces a quite novel form of PAKE protocols that employ a particular concept of ID-based encryption (IBE). The resulting cryptographic protocol is the ID-based password authenticated key exchange (I-PAKE) protocol which is a secure and efficient PAKE protocol in both soft- and hard-augmented models. I-PAKE achieves the security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also achieves the great efficiency by allowing the whole pre-computation of the ephemeral Diffie-Hellman public keys by both server and client. |
| | Building power shortest inter-Area TE LSPs using pre-computed paths |
| |
|
In this paper, we propose a framework to reduce the aggregate power consumption of an Autonomous System (AS) using a collaborative approach between areas within an AS. We identify the low-power paths within non-backbone areas and then use Traffic Engineering (TE) techniques to route the packets along the stitched paths from non- backbone areas / backbone area to other non-backbone areas. Such low- power paths can be identified by using the power-to-available- bandwidth (PWR) ratio as an additional constraint in the Constrained Shortest Path First (CSPF) algorithm. For routing the data traffic through these low-power paths, the Inter-Area Traffic Engineered Label Switched Path (TE-LSP) that spans multiple areas can be used. Extensions to the Interior Gateway Protocols like OSPF and IS-IS that support TE extensions can be used to disseminate information about low-power paths in the respective areas (backbone or non-backbone) that minimize the PWR ratio metric on the links within the areas and between the areas thereby creating a collaborative approach to reduce the power consumption. The feasibility of our approaches is illustrated by applying our algorithm to an AS with a backbone area and several non-backbone areas. The techniques proposed in this paper for the Inter-Area power reduced paths require a few modifications to the existing features of the IGPs supporting TE extensions. The proposed techniques can be extended to other levels of Internet hierarchy, such as Inter-AS paths, through suitable modifications as in [11]. When link state routing protocols like OSPF or ISIS are used to discover TE topology, there is the limitation that traffic engineered paths can be set up only when the head and tail end of the label switched path are in the same area. There are solutions to overcome this limitation either using offline Path Computation Engine (PCE) that attach to multiple areas and know the topology of all areas. This document proposes an alternative approach that does not require any centralized PCE and uses selective leaking of low-power TE path information from one area into other areas. |
| | GOST R 34.11-2012: Hash Function |
| |
|
This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). |
| | IS-IS Topology-Transparent Zone |
| |
| | draft-chen-isis-ttz-01.txt |
| | Date: |
03/05/2013 |
| | Authors: |
Huaimo Chen, Renwei Li, Gregory Cauchie, So Ning, Alvaro Retana |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document presents a topology-transparent zone in a domain. A topology-transparent zone comprises a group of routers and a number of circuits connecting these routers. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a circuit down inside the zone is not seen by any router outside of the zone. |
| |
|
| |
| | Requirements for Energy Management |
| |
| | draft-ietf-eman-requirements-14.txt |
| | Date: |
02/05/2013 |
| | Authors: |
Juergen Quittek, Mouli Chandramouli, Rolf Winter, Thomas Dietz, Benoit Claise |
| | Working Group: |
Energy Management (eman) |
| | Formats: |
txt |
|
This document defines requirements for standards specifications for energy management. The requirements defined in this document concern monitoring functions as well as control functions. Monitoring functions include identification of energy-managed devices and their components, monitoring of their power states, power inlets, power outlets, actual power (the instantaneous power, as opposed to the demand, which is an averaged power), power attributes, received energy, provided energy, and contained batteries. Control functions serve for controlling power supply and power state of energy-managed devices and their components. This document does not specify the features that must be implemented by compliant implementations but rather features that must be supported by standards for energy management. |
| | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat |
| |
|
This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the XMPP Multi- User Chat (MUC) extension and the SIP-based Message Session Relay Protocol (MSRP). |
| | Multi-path Label Switched Paths Signaled Using RSVP-TE |
| |
|
This document describes extensions to Resource ReSerVation Protocol - Traffic Engineering for the set up of multi-path Traffic Engineered Label Switched Paths (LSPs) in Multi Protocol Label Switching and Generalized MPLS networks, i.e., LSPs that conform to traffic engineering constraints, but follow multiple independent paths from the source to the destination that allow load balancing. |
| | Aware Spanning Tree Topology Change on RBridges |
| |
|
When a local LAN running spanning tree protocol connecting to TRILL campus via more than one RBridge, there are several ways to perform loop avoidance. One of them illustrated by RFC6325 [RFC6325] A.3 was to make relevant ports on edge RBridges involving in spanning tree calculation. When edge RBridges are emulated as a single highest priority root, the local bridged LAN will be naturally partitioned after running spanning tree protocol. This approach achieves better link utilization and intra-VLAN load balancing in some scenarios. This document describes how the edge RBridges react to topology change occurring in bridged LAN in order to make the abovementioned spanning tree approach function correct. |
| | Using OSPFv3 with Role-Based Access Control |
| |
|
This note describes the changes necessary for OSPFv3 to route classes of IPv6 traffic that are defined by an IPv6 Flow Label and a destination prefix. This implies not simply routing "to a destination", but "traffic going to that destination AND using a specified flow label". It may be combined with other qualifying attributes, such as "traffic going to that destination AND using a specified flow label AND from a specified source prefix". The obvious application is data center inter-tenant routing using a form of role-based access control. If the sender doesn't know the value to insert in the flow label (the receiver's tenant ID), it in effect has no route to that destination, thus providing an access list that is as changeable and scalable as routing. |
| | IPv6 Source/Destination Routing using OSPFv3 |
| |
|
This note describes the changes necessary for OSPFv3 to route classes of IPv6 traffic that are defined by an IPv6 source prefix and a destination prefix. This implies not simply routing "to a destination", but "traffic going to that destination AND coming from a specified source". It may be combined with other qualifying attributes, such as "traffic going to that destination AND using a specified flow label AND from a specified source prefix". The obvious application is egress routing, as required for a multihomed entity with a provider-allocated prefix from each of several upstream networks. Traffic within the network could be source/destination routed as well, or could be routed from "any prefix", ::/0. If traffic is routed from the relevant PA prefixes but in fact has a source address that is in none of them, the traffic in effect has no route. |
| | VPLS external Loop Protection Mechanism (VLPM) |
| |
|
In reference and response to draft-boldy-l2vpn-vplsloop-req-01, this document describes a solution in the form of a protocol function named VPLS External Loop Protection Mechanism (VLPM). VLPM is a protocol for a service provider to deploy at the PE to detect layer-2 loops in any external layer-2 segments (customer LAN) where customer deployed loop prevention methods may have failed. After detection of such a loop it facilitates configurable actions to protect the rest of the VPLS Domain from being affected without the need for inter-operation with customer network protocols, other VPLS PEs or sites. |
| | Survey of MPTCP Implementations (blank version for implementers to fill in) |
| |
|
This survey gathers information from people who have implemented MPTCP, in particular to help progress the protocol from Experimental to Standards track. It is ready to be filled in, if you are an implementer. Thank-you! |
| | Terminology for Large MeAsurement Platforms (LMAP) |
| |
|
This documents defines terminology for Large Scale Measurement Platforms. |
| | RTP payload format for Enhanced Variable Rate Narrowband-Wideband plus 2kbps Codec (EVRC-NW2K) |
| |
|
This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband plus 2kbps Codec (EVRC-NW2K). Three media type registrations are included for EVRC-NW2K RTP payload formats. In addition, a file format is specified for transport of EVRC-NW2K speech data in storage mode applications such as e-mail. |
| | A Procedure for Cautious Delegation of a DNS Name |
| |
|
Sometimes, a DNS name is known to be in use in the wild even though it was never properly delegated. This situation appears particularly, but not only, true in certain domains near the root of the tree: people have independently used those non-existent top-level domains as private namespaces. If those names are to be delegated in the public DNS, prudence demands that collisions between the private uses and the public use be minimized. At the same time, the public use should not be prohibited on the grounds of what is, after all, "hijacking" of a name space. We outline a procedure to minimize harm while permitting delegation to proceed. |
| | Plan B: a proposal for signaling multiple media sources in WebRTC. |
| |
|
This document explains how multiple media sources can be signaled in WebRTC using SDP, in a fashion that avoids many common problems and provides a simple control surface to the receiver. |
| | Ethernet in the First Mile Copper (EFMCu) Interfaces MIB |
| |
|
This document updates RFC 5066. It amends that specification by informing the internet community about the transition of the EFM-CU- MIB module from the IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group. |
| | Security Implications of IPv6 on IPv4 Networks |
| |
|
This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. |
| | Adobe's Secure Real-Time Media Flow Protocol |
| |
|
This memo describes the Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features making it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used. |
| |
|
| |
| | Additional Managed Objects for Network Address Translators (NAT) |
| |
| | draft-ietf-behave-nat-mib-06.txt |
| | Date: |
01/05/2013 |
| | Authors: |
Simon Perreault, Tina Tsou, Senthil Sivakumar |
| | Working Group: |
Behavior Engineering for Hindrance Avoidance (behave) |
| | Formats: |
xml txt |
|
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 monitoring of a device capable of NAT function. |
| | Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale |
| |
|
OLSRv2 includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2. |
| | MPLS-TP Applicability; Use Cases and Design |
| |
|
This document provides the applicability of Multiprotocol Label Switching Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. |
| | "MPLS LSP Ping TLVs and sub-TLVs registry" |
| |
|
This document addresses issues with the structure, allocation policies and clarity in the use of the "TLVs and sub-TLVs" of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the "Multiprotocol Label Switching Architecture (MPLS)" name space. This document does not change any existing allocations and the new structure is backwards compatible with the existing registries. The policy for the allocation of TLVs is unchanged but future allocations of sub-TLVs will come from a single namespace, common to all TLVs of LSP Ping Parameters. |
| | CoRE Roadmap and Implementation Guide |
| |
|
The CoRE set of protocols, in particular the CoAP protocol, is defined in draft-ietf-core-coap in conjunction with a number of specifications that are currently nearing completion. There are also several dozen more individual Internet-Drafts in various states of development, with various levels of WG review and interest. Today, this is simply a bewildering array of documents. Beyond the main four documents, it is hard to find relevant information and assess the status of proposals. At the level of Internet-Drafts, the IETF has only adoption as a WG document to assign status - too crude an instrument to assess the level of development and standing for anyone who does not follow the daily proceedings of the WG. With a more long-term perspective, as additional drafts mature and existing specifications enter various levels of spec maintenance, the entirety of these specifications may become harder to understand, pose specific implementation problems, or be simply inconsistent. The present guide aims to provide a roadmap to these documents as well as provide specific advice how to use these specifications in combination. In certain cases, it may provide clarifications or even corrections to the specifications referenced. This guide is intended as a continued work-in-progress, i.e. a long- lived Internet-Draft, to be updated whenever new information becomes available and new consensus on how to handle issues is formed. Similar to the ROHC implementation guide, RFC 4815, it might be published as an RFC at some future time later in the acceptance curve of the specifications. This document does not describe a new protocol or attempt to set a new standard of any kind - it mostly describes good practice in using the existing specifications, but it may also document emerging consensus where a correction needs to be made. |
| | STP Application of ICCP |
| |
|
Inter-Chassis Communication Protocol (ICCP) supports the inter- chassis redundancy mechanism which achieves high network availability. In this document, the PEs in a Redundant Group (RG) running ICCP are used to offer multi-homed connectivity to Spanning Tree Protocol (STP) networks. The ICCP TLVs for the STP application are defined, therefore PEs from the RG can make use of these TLVs to synchronize the state and configuration data. |
| | OAuth Token Introspection |
| |
|
This specification defines a method for a client or protected resource to query an OAuth authorization server to determine meta- information about an OAuth token. |
| | RADIUS Extended Request |
| |
|
This document describes methods for RADIUS servers to communicate optional extended abilities to RADIUS clients. The abilities described provide for exchange of RADIUS packets where total packet length exceeds 4096 bytes. |
| | OSPFv3 LSA Extendibility |
| |
|
OSPFv3 requires functional extension beyond what can be done with the fixed Link State Advertisement (LSA) format as described in RFC 5340. This document extends the LSA format by allowing the optional inclusion of Type-Length-Value (TLV) tuples in the LSAs. It also covers all the aspects of backward compatibility. |
| | Use Cases for DC Network Virtualization Overlays |
| |
| | draft-ietf-nvo3-use-case-01.txt |
| | Date: |
01/05/2013 |
| | Authors: |
Lucy Yong, Mehmet Toy, Aldrin Isaac, Vishwas Manral, Linda Dunbar |
| | Working Group: |
Network Virtualization Overlays (nvo3) |
| | Formats: |
txt |
|
This document describes the DC NVO3 use cases that may be potentially deployed in various data centers and apply to different applications. An application in a DC may be a combination of some use cases described here. |
| |
|
| |
| | Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices |
| |
|
The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. |
| | Applicability of MPLS-TP Linear Protection for Ring Topologies |
| |
| | draft-ietf-mpls-tp-ring-protection-06.txt |
| | Date: |
30/04/2013 |
| | Authors: |
Yaacov Weingarten, Stewart Bryant, Daniele Ceccarelli, Diego Caviglia, Francesco Fondelli, Marco Corsi, Wu Bo, Xuehui Dai |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
| | Formats: |
xml txt |
|
This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to Multi-Protocol Label Switching Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Protection on rings offers a number of opportunities for optimization as the protection choices are starkly limited (all traffic traveling one way around a ring can only be switched to travel the other way on the ring), but also suffers from some complications caused by the limitations of the topology. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document shows how MPLS-TP linear protection as defined in RFC 6378 can be applied to single ring topologies, discusses how most of the requirements are met, and describes scenarios in which the function provided by applying linear protection in a ring topology falls short of some of the requirements. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
| | The application/firmware,application/firmware-receipt,and application/firmware-error media types |
| |
|
This document registers the application/firmware, application/firmware-receipt and application/firmware-error media media types for use with the corresponding CMS (Cryptographic Message Syntax) content types defined in RFC 4108. |
| | Network Reconnaissance in IPv6 Networks |
| |
|
IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore IPv6 address scanning attacks have long been considered unfeasible. This document analyzes how traditional address scanning techniques apply to IPv6 networks, and also explores a number of other techniques that can be employed for IPv6 network reconnaissance. Additionally, this document formally obsoletes RFC 5157. |
| |
|
| |
| | Distributing Address Selection Policy using DHCPv6 |
| |
|
RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 6724 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site. |
| | Realm-Based Redirection In Diameter |
| |
|
The Diameter protocol allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document. This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. |
| | URN For Country Specific Emergency Services |
| |
|
This document updates section 4.2 of RFC 5031, in order to allow the registration of service URNs with the 'sos' service type for emergency services that, at the time of registration, are offered in one country only. |
| | IODEF Usage Guidance |
| |
|
The Incident Object Description Exchange Format [RFC5070] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for implementers to develop tools that can Leverage IODEF for incident sharing. This document provides guidelines for IODEF users and implementers. It will also address how common security indicators can be represented in IODEF. The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world. |
| | A Forward-Search P2P TE LSP Inter-Domain Path Computation |
| |
|
This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. |
| | A Forward-Search P2MP TE LSP Inter-Domain Path Computation |
| |
|
This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. |
| | The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks. |
| |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. |
| | Signaling Virtual Machine Activity to the Network Virtualization Edge |
| |
|
This document proposes a simplified approach for provisioning network parameters related to Virtual Machine creation, migration and termination on servers. The idea is to provision the server, then have the server signal the requisite parameters to the relevant network device(s). Such an approach reduces the workload on the provisioning system and simplifies the data model that the provisioning system needs to maintain. It is also more resilient to topology changes in server-network connectivity, for example, reconnecting a server to a different network port or switch. |
| | Using Extended Key Usage (EKU) for REsource LOcation And Discovery (RELOAD) X.509 Certificates |
| |
|
This document describes an Extended Key Usage (EKU) X.509 certificate extension for restricting the usage of a certificate to a REsource LOcation And Discovery (RELOAD) overlay. |
| | Attacks on Cryptographic Hashes in Internet Protocols |
| |
|
Announcements in the past decade of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. It also gives rationales for moving away from some hash algorithms altogether and for choosing when to start using newer, presumably better, hash algorithms in Internet protocols. This document obsoletes RFC 4270 and introduces significant new material that has been learned since the publication of that document. |
| | Using DMARC |
| |
|
Email abuse often relies on unauthorized use of a domain name, such as one belonging to a well-known company (brand). SPF and DKIM provide basic domain name authentication methods for email. A recent industry effort built an additional authentication-based layer, called Domain-based Message Authentication, Reporting & Conformance (DMARC). It allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes; it also provides a reporting mechanism, from receivers back to domain owners. Such capabilities over the public Internet are unusual and their use is not yet well-understood. This document formulates a set of best practices for the use of DMARC. |
| |
|
| |
| | The Binary Floor Control Protocol (BFCP) |
| |
| | draft-ietf-bfcpbis-rfc4582bis-09.txt |
| | Date: |
26/04/2013 |
| | Authors: |
Gonzalo Camarillo, Keith Drage, Tom Kristensen, Joerg Ott, Charles Eckel |
| | Working Group: |
Binary Floor Control Protocol Bis (bfcpbis) |
| | Formats: |
txt xml |
|
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. |
| | Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams |
| |
|
This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 12. |
| | DHCPv4 over DHCPv6 Transport |
| |
|
This document describes a mechanism for obtaining IPv4 address and other parameters in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. |
| | PCEP extensions for a BGP/MPLS IP-VPN |
| |
|
IP Virtual Private Networks (IP-VPNs) allow Service Providers to offer customers connectivity between sites across an IP Backbone. These VPNs can be supported using BGP/MPLS and the connections can be created by using MPLS Traffic Engineered (TE) Label Switched Paths (LSPs). The paths of these LSPs must be computed to provide the connectivity between customer sites. Path selection may be dependent on a variety of factors including traffic engineering constraints and bandwidth requirements. It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs for interconnectivity between BGP/MPLS IP-VPN sites. The Path Computation Element (PCE) can determine the optimal paths of TE LSPs within an MPLS network. This document defines how to extend the PCEP to support the dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites. |
| | CoAP Minimum Request Interval |
| |
|
This document defines an "Minimum-Request-Interval" option for CoAP, which can be used to negotiate the minimum time between two subsequent requests within a single client and server pair. It can be used for flow and congestion control, reducing the consumption of server and network resources when needed. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. |
| | Extensions to Resource Reservation Protocol For Fast Reroute of Bidirectional Co-routed Traffic Engineering LSPs |
| |
|
This document defines RSVP-TE signaling extensions to support Fast Reroute (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs. These extensions enable the re-direction of bi-directional traffic and signaling onto bypass tunnels that ensure co-routedness of data and signaling paths in the forward and reverse directions after FRR. In addition, the RSVP-TE signaling extensions allow the coordination of bypass tunnel assignment protecting a common facility in both forward and reverse directions prior to or post failure occurrence. |
| | Service Advertisement using BGP |
| |
|
A variety of services, such as NATs, firewalls, or caches, can be embedded in a service provider network or instantiated in data centers attached to the network. This document proposes extensions to BGP that facilitate discovery of such service instances by interested clients and allows dissemination of service information, such as services capabilities or capacities, thoughtout the network domain. The proposed extensions allow for optimal routing of requests to service instances that can optimally serve them. |
| | Applicability of LDP Multi-Topology for Unicast Fast-reroute Using Maximally Redundant Trees |
| |
|
In this document, procedures' considerations on the applicability of LDP MT for unicast fast-reroute using MRT are provided. The behaviors of label allocation and label forwarding entry setup with LDP Multi-Topology and MRT fast-reroute are described in details. Different application scenarios of the combining of the LDP multi- topology(MT) and unicast fast-reroute using Maximally Redundant Trees(MRT) are also analyzed. |
| | Profile Support for the Atom Syndication Format |
| |
|
The Atom syndication format is a generic XML format for representing collections. Profiles are one way how Atom feeds can indicate that they support specific extensions. To make this support visible on the media type level, this specification re-registers the Atom media type, and adds a "profile" media type parameter. This allows profiles to become visible at the media type level, so that servers as well as clients can indicate support for specific Atom profiles in conversations, for example when communicating via HTTP. |
| | Non-Gregorian Recurrence Rules in iCalendar |
| |
|
This document defines how non-Gregorian recurrence rules can be specified in iCalendar data. |
| | TRILL Integrated Routing and Bridging Solution |
| |
|
Currently, TRILL solution can only provide optimum unicast forwarding just for Layer2 traffic of intra-subnet forwarding, not for Layer3 traffic(inter-subnet forwarding). In this document, a TRILL Integrated Routing and Bridging (IRB) solution is introduced to provide optimum unicast forwarding not just for Layer 2 traffic (intra-subnet forwarding), but also for Layer 3 traffic (inter- subnet forwarding). In the TRILL IRB scenario, an edge RB MUST perform the bridging function for the End Systems that are on the same subnet and the IP routing for the End Systems that are on the different subnets of same tenant. |
| | OSPFv3 Instance ID Registry Update |
| |
|
This document modifies the "Unassigned" number space in the IANA "OSPFv3 Instance ID Address Family Values" registry by dividing it in two halves, one half Unassigned but managed via Standards Action, and the other Reserved for Private Use. It updates [RFC5838]. |
| | Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function |
| |
|
This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. A UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP (Customer Premises) routers to allow for transparent NAT control in environments where UPnP IGD is used on the LAN side and PCP on the external side of the CP router. |
| | SEND-based Source-Address Validation Implementation |
| |
| | draft-ietf-savi-send-10.txt |
| | Date: |
26/04/2013 |
| | Authors: |
Marcelo Bagnulo, Alberto Garcia-Martinez |
| | Working Group: |
Source Address Validation Improvements (savi) |
| | Formats: |
txt |
|
This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a finer granularity on the control of the source addresses used. |
| | RADIUS Attribute for MAP |
| |
|
Mapping of Address and Port (MAP) is a stateless mechanism for running IPv4 over IPv6-only infrastructure. It provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co- existing period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) MAP options has been defined to configure MAP Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCPv6 protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries MAP configuration information from AAA server to BNG. The MAP RADIUS attribute are designed following the simplify principle. It provides just enough information to form the correspondent DHCPv6 MAP option. |
| | TRILL (Transparent Interconnection of Lots of Links): Edge Directory Assistance Framework |
| |
|
Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End Station Address Distribution Information) protocol. When an ingress TRILL switch receives a data frame whose destination address (MAC&VLAN) that switch does not know, the data frame is flooded within the frame's VLAN across the TRILL campus. This document describes the framework for using directory services to assist edge RBridges in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND, thus improving TRILL network scalability. |
| |
|
| |
| | Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge Routers |
| |
|
The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 relay agent implemented on a Provider Edge (PE) router about active prefix pools allocated by the DHCPv6 server to the PE router. The information of active prefix pools can be used to enforce IPv6 route aggregation on the PE router through adding or removing aggregation routes according to the status of the prefix pools. The advertising of the aggregation routes in the routing protocol enabled on the network-facing interface of PE routers will dramatically decreases the number of the routing table entries in the ISP network. |
| | Compression Extensions for WebSocket |
| |
|
This document specifies a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of non-control WebSocket messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method to apply a compression algorithm to the contents of WebSocket messages. For each compression algorithm, an extension is defined by specifying parameter negotiation and compression algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm. Please send feedback to the hybi@ietf.org mailing list. |
| | Notification Message support for BGP Graceful Restart |
| |
|
The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. |
| | A YANG Data Model for SNMP Configuration |
| |
|
This document defines a collection of YANG definitions for configuring SNMP engines. |
| | Delay-Tolerant Networking LTP Convergence Layer (LTPCL) Adapter |
| |
|
This document describes the procedures by which the Licklider Transmission Protocol (LTP) is used as a "convergence-layer" protocol to convey Delay-Tolerant Networking (DTN) "bundles" between DTN nodes. |
| | Analysis of Port Control P0rotocol in Mobile Network |
| |
|
This memo provides a motivation description for the Port Control Protocol (PCP) deployment in a 3GPP mobile network environment. The document focuses on a mobile network specific issues (e.g. cell phone battery power consumption, keep-alive traffic reduction), PCP applicability to these issues is further studied and analyzed. |
| | Forwarding and Control Element Separation (ForCES) OpenFlow Model Library |
| |
|
This document describes the OpenFlow switch in Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The LFB classes are defined according to the ForCES Forwading Element (FE) model and ForCES protocol specifications. The library includes the descriptions of the OpenFlow LFBs and the XML definitions. |
| | Opportunistic Routing based on Users Daily Life Routine |
| |
| | draft-moreira-dlife-02.txt |
| | Date: |
25/04/2013 |
| | Authors: |
Waldir Moreira, Paulo Mendes, Ronedo Ferreira, Douglas Cirqueira, Eduardo Cerqueira |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document is written in the context of the Delay Tolerant Networking Research Group and will be presented for reviewing by that group. This document defines dLife, an opportunistic routing protocol that takes advantage of time-evolving social structures. dLife belongs to the family of social-aware opportunistic routing protocols for intermittently connected networks. dLife operates based on a representation of the dynamics of social structures as a weighted contact graph, where the weights (i.e., social strengths) express how long a pair of nodes is in contact over different period of times. It considers two complementary utility functions: Time-Evolving Contact Duration (TECD) that captures the evolution of social interaction among pairs of users in the same daily period of time, over consecutive days; and TECD Importance (TECDi) that captures the evolution of user's importance, based on its node degree and the social strength towards its neighbors, in different periods of time. It is intended for use in wireless networks where there is no guarantee that a fully connected path between any source - destination pair exists at any time, a scenario where traditional routing protocols are unable to deliver bundles. Such networks can be sparse mesh, in which case intermittent connectivity is due to lack of physical connections, or dense mesh, in which case intermittent connectivity may be due to high interference or shadowing. In any case, intermittent connectivity can also be due to the availability of devices (e.g., unavailable due to power saving rules). The document presents an architectural overview followed by the protocol specification. |
| | Vulnerability Data Model |
| |
|
This Internet-Draft describes the Vulnerability Data Model (VDM) version 1.0, a vendor neutral data model for expressing data and metadata for individual vulnerabilities, and an XML format that can be used to exchange vulnerability data model information. VDM provides standard fields, formats and vocabularies that can be used to transmit information about software vulnerabilities between entities in an interoperable manner. VDM is suited for a wide variety of use cases, and provides extension points to facilitate additional use cases. |
| | RSVP-TE LSP egress fast-protection |
| |
|
RFC4090 defines a fast reroute mechanism for locally repairing an RSVP-TE LSP in the order of 10s of milliseconds, in the event of a downstream link or node failure. However, this mechanism does not provide node protection for LSP egress nodes, even when an alternate egress node (a backup egress) is available that could carry the traffic to its ultimate destination. This document addresses this scenario and describes how to provide egress protection by establishing a bypass LSP from the penultimate-hop node of a LSP to the backup egress node. The methods described in this document enable local repair in the order of 10s of milliseconds, in the event of the egress node failure. These methods are only applicable if traffic carried by the LSP can be rerouted to its ultimate destination by the backup egress node. |
| | A Framework for SDP Attributes when Multiplexing |
| |
|
The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. In the RTCWeb WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Sessions multiplexed over a single transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. The specification also categorizes existing attributes based on the framework described herein. |
| | A SASL and GSS-API Mechanism for the BrowserID Authentication Protocol |
| |
|
This document defines protocols, procedures and conventions for a Generic Security Service Application Program Interface (GSS-API) security mechanism based on the BrowserID authentication mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications may use BrowserID. |
| | PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols |
| |
|
Application protocols using Unicode code points in protocol strings need to properly prepare such strings in order to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation and comparison of internationalized strings (a.k.a. "PRECIS") in a way that depends on the properties of Unicode code points and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). A specification that reuses this framework can either directly use the PRECIS string classes or subclass the PRECIS string classes as needed. This framework takes an approach similar to the revised internationalized domain names (IDNs) in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in the IAB's recommendations regarding IDNs (RFC 4690), albeit for application technologies other than the Domain Name System (DNS). This document obsoletes RFC 3454. |
| | Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords |
| |
|
This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013. |
| | IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd) |
| |
| | draft-ietf-softwire-4rd-05.txt |
| | Date: |
25/04/2013 |
| | Authors: |
Remi Despres, Sheng Jiang, Reinaldo Penno, Yiu Lee, Gang Chen, Maoke Chen |
| | Working Group: |
Softwires (softwire) |
| | Formats: |
txt |
|
The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customer sites can be assigned shared public IPv4 addresses with restricted port sets. 4rd can also support the scenarios that customer sites are assigned full public IPv4 addresses or a set of public IPv4 addresses. |
| | Security Requirements of Time Protocols in Packet Switched Networks |
| |
|
As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols and the dependencies between other security services and time synchronization. |
| | Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension |
| |
|
This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation within the TLS handshake. For instances in which the TLS connection is established over a well known TCP/IP port not associated with the desired application layer protocol, this extension allows the application layer to negotiate which protocol will be used within the TLS session. |
| | Extensible Messaging and Presence Protocol (XMPP): Address Format |
| |
|
This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. |
| | RTP Control Protocol(RTCP) Extended Report (XR) Block for Burst/Gap Discard metric Reporting |
| |
|
This document defines an RTP Control Protocol(RTCP) Extended Report (XR) Block that allows the reporting of Burst and Gap Discard metrics for use in a range of RTP applications. |
| |
|
| |
| | Neighbor Unreachability Detection is too impatient |
| |
|
IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative neighbor, for instance when there are multiple default routers, since it allows the host to switch to the alternative neighbor in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternative neighbors, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC 4861. |
| | Logical Interface Support for multi-mode IP Hosts |
| |
|
A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. |
| | Congestion control algorithm for lower latency and lower loss media transport |
| |
|
This memo provides a design for a congestion control algorithm, for media transport, which aims to provide for lower delay and lower loss communications. |
| | Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks |
| |
|
Demands on networking infrastructure are growing exponentially; the drivers are bandwidth hungry rich media applications, inter-data center communications, etc. In this context, it is important to optimally use the bandwidth in wired networks that extensively use LAG/ECMP techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. |
| | X.509v3 TLS Feature Extension |
| |
|
The purpose of the TLS Feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS Feature extension may be used to mandate support for revocation checking features in the TLS protocol such as OCSP stapling. Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled. This in turn prevents a denial of service attack that might otherwise be possible. |
| | DNS-like system for OID |
| |
|
This file justifies and explains a DNS-like system for storing the correspondence between OID names and numbers, as well as some additional data that might be deemed useful. It is aimed to be implemented as an extension to current DNS mechanisms by the addition of some Resource Record and Query types. |
| |
|
| |
| | Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) |
| |
| | draft-ietf-avtcore-6222bis-03.txt |
| | Date: |
23/04/2013 |
| | Authors: |
Ali Begen, Colin Perkins, Dan Wing, Eric Rescorla |
| | Working Group: |
Audio/Video Transport Core Maintenance (avtcore) |
| | Formats: |
txt |
|
The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. |
| | Handling Unknown DHCPv6 Messages |
| |
|
Dynamic Host Configuration Protocol version 6 (DHCPv6) isn't specific about handling messages with unknown types. This document describes the problems and defines how a DHCPv6 function node should behave in this case. This document updates RFC3315. |
| | Rate Measurement Test Protocol Problem Statement |
| |
|
This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. The rate measurement scenario has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. |
| | Applicability of Proxy Mobile IPv6 Protocol for WLAN Access Networks |
| |
|
Proxy Mobile IPv6 is a network-based mobility management protocol. The protocol is designed for providing mobility management support to a mobile node, without requiring its participation in any IP mobility related signaling. The base protocol is defined in an access technology independent manner, it identifies the general requirements from the link-layer for supporting the protocol operation. However, it does not provide any specific details on how it can be supported on a specific access technology. This specification identifies the key considerations for supporting Proxy Mobile IPv6 protocol on the widely deployed wireless LAN access architectures, based on IEEE 802.11 standards. It explores the current dominant wireless LAN deployment models and provides the needed interworking details. |
| | Adaptive VLAN Assignment for Data Center RBridges |
| |
|
If RBridges are casually assigned as Appointed Forwarders for VLANs without considering the number of MAC addresses and traffic load of these VLANs, it may overload some of the RBridges while leave other RBridges lightly loaded, which reduces the scalability of a RBridge network and undermines its performance. A new mechanism is designed in this document to support the adaptive VLAN assignment (or Appointed Forwarder selection) based on the forwarders' reporting of their usage of MAC tables and available bandwidth. |
| | Energy Management Terminology |
| |
|
This document contains definitions and terms used in the Energy Management Working Group. Each term contains a definition(s), example, and reference to a normative, informative or well know source. Terms originating in this draft should be either composed of or adapted from other terms in the draft with a source. The defined terms will then be used in other drafts as defined here. |
| | CoAP Option Extension: Patience |
| |
|
CoAP is a RESTful application protocol for constrained nodes and networks. This specification provides a simple extension for CoAP, the Patience option. This option informs a recipient of the preferred time frame for a request or response depending on usage context. In a unicast request, it indicates the patience a client has in waiting for a response. The CoAP server tries to return the response within the specified time frame. In a multicast request, it indicates the patience a server should have in sending its response. The recipient would then try to randomly delay its response within the time frame that the requester indicated or computed by the recipient itself. In a CoAP observe notification, it indicates the patience an observer should have in both waiting for a subsequent notification and in re-establishing an observation relation. |
| | Service Provider Wi-Fi Services Over Residential Architectures |
| |
|
The tremendous growth in Wi-Fi technology adoption over the last decade has met the ultimate possible goal of 100% adoption rate. All most every new mobile device is now equipped with IEEE 802.11-based wireless interface and with pre-configured policy to prefer Wi-Fi to cellular access. Matching this evolution is every service provider's desire to offer Wi-Fi based broadband services; a new business opportunity even for fixed line operators. Operators are exploring options to monetize their existing networks, most with nation-wide footprint, to build a high-speed Wi-Fi service that can be the basis for offering new wireless broadband services. This document identifies the requirements for supporting these new Wi-Fi community services and the mobility tools which have been standardized in IETF that can be used for enabling these architectures. |
| | TRILL Resilient Distribution Trees |
| |
|
TRILL protocol provides layer 2 multicast data forwarding using IS-IS link state routing. Distribution trees are computed based on the link state information through Shortest Path First calculation and shared among VLANs across the campus. When a link on the distribution tree fails, a campus-wide recovergence of this distribution tree will take place, which can be time consuming and may cause considerable disruption to the ongoing multicast service. This document proposes to build the backup distribution tree to protect links on the primary distribution tree. Since the backup distribution tree is built up ahead of the link failure, when a link on the primary distribution tree fails, the pre-installed backup forwarding table will be utilized to deliver multicast packets without waiting for the campus-wide recovergence, which minimizes the service disruption. |
| | Proposed Control Plane requirements for Network Virtualization Overlays |
| |
|
This document focuses on control plane aspect related to both tenant system to NVE control interface and NVE to Network Virtualization Authority (NVA) control interface NVE use to enable communication between tenant systems, which is complementary to [draft-kreeger-nvo3-hypervisor-nve-cp] that describes the high level control plane requirements related to the interaction between tenant system and NVE when the two entities are not co-located on the same physical device. |
| | Delay Tolerant Networking Email Convergence Layer Protocol |
| |
|
This document describes the protocol for the Email-based Convergence (MCL) Layer for Delay Tolerant Networking (DTN). |
| | IETF Recommendations Regarding Active Queue Management |
| |
|
This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. The note largely repeats the recommendations of RFC 2309, updated after fifteen years of experience and new research. |
| | IMAP4 non-synchronizing literals |
| |
|
The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. |
| | TRILL Over Pseudowires |
| |
| | draft-yong-trill-o-pw-00.txt |
| | Date: |
23/04/2013 |
| | Authors: |
Lucy Yong, Donald Eastlake, Sam Aldrin, Jon Hudson |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document specifies how to interconnect a pair of TRILL (Transparent Interconnection of Lots of Links) switch ports using pseudowires under existing TRILL and PWE3 (Pseudowire Emulation End- to-End) standards. |
| | OSPF Stub Router Advertisement |
| |
| | draft-ietf-ospf-rfc3137bis-04.txt |
| | Date: |
23/04/2013 |
| | Authors: |
Alvaro Retana, Liem Nguyen, Alex Zinin, Russ White, Danny McPherson |
| | Working Group: |
Open Shortest Path First IGP (ospf) |
| | Formats: |
txt |
|
This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic, or to lower the preference level for the paths through such a router. This document obsoletes [RFC3137]. |
| | The Port Control Protocol in Dual-Stack Lite environments |
| |
| | draft-dupont-pcp-dslite-05.txt |
| | Date: |
23/04/2013 |
| | Authors: |
Francis Dupont, Tina Tsou, Jacni Qin, Margaret Wasserman, Dacheng Zhang |
| | Working Group: |
Port Control Protocol (pcp) |
| | Formats: |
xml txt |
|
This document specifies the so-called "plain mode" for the use of the Port Control Protocol (PCP) in Dual-Stack Lite (DS-Lite) environments. |
| | Using the ECC Brainpool Curves for IKEv2 Key Exchange |
| |
|
This document specifies the use of ECC Brainpool elliptic curve groups for key exchange in the Internet Key Exchange version 2 (IKEv2) protocol. |
| |
|
| |
| | Guidelines for using the Multiplexing Features of RTP |
| |
|
Real-time Transport Protocol (RTP) is a flexible protocol possible to use in a wide range of applications and network and system topologies. This flexibility and the implications of different choices should be understood by any application developer using RTP. To facilitate that understanding, this document contains an in-depth discussion of the usage of RTP's multiplexing points; the RTP session and the Synchronisation Source Identifier (SSRC). The document tries to give guidance and source material for an analysis on the most suitable choices for the application being designed. |
| | RTP Considerations for Endpoints Sending Multiple Media Streams |
| |
|
This document expands and clarifies the behavior of the Real-Time Transport Protocol (RTP) endpoints when they are sending multiple media streams in a single RTP session. In particular, issues involving Real-Time Transport Control Protocol (RTCP) messages are described. This document updates RFC 3550 in regards to handling of multiple SSRCs per endpoint in RTP sessions. |
| | RTP Topologies |
| |
|
This document discusses point to point and multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document is updated with additional topologies and are intended to replace RFC 5117. |
| | Power and Energy Monitoring MIB |
| |
|
This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. |
| | Terminology for Constrained Node Networks |
| |
|
The Internet Protocol Suite is increasingly used on small devices with severe constraints, creating constrained node networks. This document provides a number of basic terms that have turned out to be useful in the standardization work for constrained environments. |
| | Per-Interface MIP Addressing Requirements and Design Considerations |
| |
|
The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. More precisely it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. |
| | RO Extensions for PMIPv6-LR (ROEXT) |
| |
|
The communication path between two Hosts within a Proxy Mobile IPv6 domain is artificially long - it involves the LMA, even if straight paths exist (under same MAG, or MAG-to-MAG). Localized Routing PMIPv6-LR concepts developped by NETEXT WG make use of LRI/LRA messages to achieve optimized MAG-to-MAG straight paths. This may prove inconvenient for the network operator, in that it may loose ability to control traffic (LMA control point is skipped). In this draft we present a middle-ground solution. It employs new Intermediary Anchors (IAs) in the paths between MAGs and offers points of control of traffic useful for QoS and lawful interception. |
| | MPLS-TP protection for interconnected rings |
| |
|
The requirements for MPLS Transport Profile include a requirement (R93) that requires MPLS-TP must support recovery mechanisms for a network constructed from interconnected rings that protect user data that traverses more than one ring. In particular, This includes protecting against cases of failure at the ring-interconnect nodes and links. This document presents different scenario of interconnected rings and special mechanism to address recovery of the failure of ring-interconnect nodes and links. . This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
| | HTTP Link and Unlink Methods |
| |
|
This specification defines the semantics of the Link and Unlink HTTP methods. |
| | Session Peering Provisioning (SPP) Protocol over REST |
| |
|
The Session Peering Provisioning Framework (SPPF) is a framework that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. This SPP Protocol implementation follows the REST architectural principles over HTTP to allow efficient provisioning of session establishment data. The benefits include inter alia better performances under high loads through the use of HTTP caches and proxies and less coupling between clients and servers. This document describes the specification of a protocol for transporting SPPF structures over HTTP(s) following REST architectural principles. |
| | A One-Way Delay Metric for IPPM |
| |
|
This memo (RFC 2679 bis) defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. |
| | Conveying Vendor-Specific Constraints in the Path Computation Element Protocol |
| |
|
The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object. |
| |
|
| |
| | Support for Multiple Clock Rates in an RTP Session |
| |
|
This document clarifies the RTP specification when different clock rates are used in an RTP session. It also provides guidance on how to interoperate with legacy RTP implementations that use multiple clock rates. |
| | Using Saratoga with a Bundle Agent as a Convergence Layer for Delay- Tolerant Networking |
| |
| | draft-wood-dtnrg-saratoga-12.txt |
| | Date: |
21/04/2013 |
| | Authors: |
Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
Saratoga is a simple, lightweight, UDP-based transfer protocol. This describes how to use Saratoga as a Delay-Tolerant Networking (DTN) "convergence layer" with the Bundle Protocol and its Bundle Agents, building on the Saratoga specification in draft-wood-tsvwg-saratoga. |
| | Saratoga: A Scalable Data Transfer Protocol |
| |
| | draft-wood-tsvwg-saratoga-13.txt |
| | Date: |
21/04/2013 |
| | Authors: |
Lloyd Wood, Wesley Eddy, Charles Smith, Will Ivancic, Chris Jackson |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document specifies the Saratoga transfer protocol. Saratoga was originally developed to transfer remote-sensing imagery efficiently from a low-Earth-orbiting satellite constellation, but is useful for many other scenarios, including ad-hoc peer-to-peer communications, delay-tolerant networking, and grid computing. Saratoga is a simple, lightweight, content dissemination protocol that builds on UDP, and optionally uses UDP-Lite. Saratoga is intended for use when moving files or streaming data between peers which may have permanent, sporadic or intermittent connectivity, and is capable of transferring very large amounts of data reliably under adverse conditions. The Saratoga protocol is designed to cope with highly asymmetric link or path capacity between peers, and can support fully-unidirectional data transfer if required. Saratoga can also cope with very large files for exascale computing. In scenarios with dedicated links, Saratoga focuses on high link utilization to make the most of limited connectivity times, while standard congestion control mechanisms can be implemented for operation over shared links. Loss recovery is implemented via a simple negative-ack ARQ mechanism. The protocol specified in this document is considered to be appropriate for experimental use on private IP networks. |
| | TFRC-based Congestion Control for Saratoga |
| |
|
This document specifies the use of TCP-Friendly Rate Control (TFRC) with the Saratoga data transfer protocol. The necessary conventions that a Saratoga sender and receiver implementation must follow if they wish to enable the use of TFRC are described. |
| | Congestion control for the Saratoga protocol |
| |
|
Saratoga is a data transfer protocol designed to carry potentially large volumes of data over difficult network paths, often including only a single high-rate link and only one application flow. As the requirements for use vary across deployment environments, the base Saratoga specification only assumes that an implementation will be able to clock packets out at a configurable rate, and beyond this specifies no inherent or particular congestion-control behaviour. The design of Saratoga deliberately supports the integration of congestion-control algorithms without modification to the base protocol. This document describes how congestion control can be supported in the Saratoga transfer protocol. Saratoga is intended for use in private networks, where its use is engineered as a single flow to fill a link. However, as Saratoga is implemented over UDP, it can be multiplexed, and can be run across the public Internet, in which case congestion control in accordance with the UDP Guidelines becomes necessary. |
| | Mapping PMIP Quality of Service in WiFi Network |
| |
|
This document proposes a model for configuring and mapping PMIP QoS parameters of a mobile network session to the corresponding connection at a WiFi Access Point. In congested network conditions, it is useful for an MN's flows to be policed and shaped at the WLC and WiFi AP to match bandwidth constraints or service priority of the user's subscription. Applying similar QoS management at the WiFi AP and WLC allows optimal use of network resources. Currently, the WiFi AP does not have information on the MNs subscribed bandwidth, or relative priority of its flows or services for per user QoS handling at the WiFi AP. This document provides a model for mapping PMIP QoS to corresponding 802.11e QoS parameters. |
| | Techniques for Tracking Inventory Using DHCPv6 DUID |
| |
|
In the years since DHCPv4 gained widespread popularity, one of the uses to which organizations have put it is inventory tracking: associating identifiers scanned from packaging with records in an inventory database. This document describes various means for accomplishing the same purpose using DHCPv6. This document also updates RFC3315 by clarifying the meaning of some normative language regarding the DUID-LL and DUID-LLT DUID types. |