| draft-abdo-hostid-tcpopt-implementation-02.txt | |||||||||||||||||
| HOST_ID TCP Options: Implementation & Preliminary Test Results | |||||||||||||||||
|
This memo documents the implementation of the HOST_ID TCP Options. It also discusses the preliminary results of the tests that have been conducted to assess the technical feasibility of the approach as well as its scalability. Several HOST_ID TCP options have been implemented and tested. | ||||||||||||||||
| draft-accilent-at-sign-00.txt | |||||||||||||||||
| Clarification of Proper Use of "@" (at sign) in URI-style Components | |||||||||||||||||
|
Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. | ||||||||||||||||
| draft-acee-ospf-ospfv3-autoconfig-01.txt | |||||||||||||||||
| OSPFv3 Auto-Configuration | |||||||||||||||||
|
OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. | ||||||||||||||||
| draft-agl-tls-nextprotoneg-04.txt | |||||||||||||||||
| Transport Layer Security (TLS) Next Protocol Negotiation Extension | |||||||||||||||||
|
This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation. This allows the application layer to negotiate which protocol should be performed over the secure connection. | ||||||||||||||||
| draft-ahn-manet-aodv-stableroute-00.txt | |||||||||||||||||
| An AODV Extension for Stable Route Selection | |||||||||||||||||
|
This document describes an enhancement on AODV that can allow a route with more stable intermediate nodes to be selected. For this, a new field, called the 'RouteStability' field, is introduced in the RREQ message and in the AODV routing table entry. | ||||||||||||||||
| draft-ahn-manet-centralized-dns-00.txt | |||||||||||||||||
| A Centralized MANET DNS Mechanism | |||||||||||||||||
|
This document describes a Domain Name System (DNS) mechanism for the MANET based on the centralized DNS mechanism used in the wired Internet. In order to adapt to the dynamic topology changes of the MANET, the mechanism handles the movement of the DNS server and the MANET merge/partition. | ||||||||||||||||
| draft-aitken-ipfix-unobserved-fields-00.txt | |||||||||||||||||
| Reporting Unobserved Fields in IPFIX | |||||||||||||||||
|
The IPFIX protocol is designed to export information about observations, and lacks a method for reporting that observations are unavailable. This document discusses several methods for reporting when fields are unavailable, reviews the advantages and disadvantage of each, and recommends methods which should be used. | ||||||||||||||||
| draft-akhter-opsawg-perfmon-ipfix-02.txt | |||||||||||||||||
| IPFIX Information Elements for Flow Performance Measurement | |||||||||||||||||
|
There is a need to be able to quantify and report the performance of network applications and the network service in handling user data. This performance data provides information essential in validating service level agreements, fault isolation as well as early warnings of greater problems. This document describes IPFIX Information Elements related to performance measurement of network based applications. In addition, to the performance information several non-metric information elements are also included to provide greater context to the reports. The measurements use audio/video applications as a base but are not restricted to these class of applications. | ||||||||||||||||
| draft-akhter-opsawg-perfmon-method-02.txt | |||||||||||||||||
| Methodology for Network Flow Performance Measurement | |||||||||||||||||
|
There is a need to be able to quantify and report the performance of network applications and the network service in handling user data. This performance data provides information essential in validating service level agreements, fault isolation as well as early warnings of network greater problems. This document describes a generic methodology for calculating metrics related to network based applications. In addition, to the performance metrics, several additional information elements are included to help provide greater context to the reports. The measurements use audio/video applications as base examples but are not restricted to these class of applications. | ||||||||||||||||
| draft-akiya-bfd-intervals-01.txt | |||||||||||||||||
| Standardized interval support in BFD | |||||||||||||||||
|
This document defines a set of interval values that we call "Standard intervals". Values of this set must be supported for transmitting BFD control packets and for calculating the detection time in the receive direction when the value is equal or larger than the fastest, i.e. lowest, interval a particular BFD implementation supports. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. | ||||||||||||||||
| draft-aks-crypto-sensors-02.txt | |||||||||||||||||
| Practical Considerations and Implementation Experiences in Securing Smart Object Networks | |||||||||||||||||
|
This memo describes challenges associated with securing smart object devices in constrained implementations and environments. The memo describes a possible deployment model suitable for these environments, discusses the availability of cryptographic libraries for small devices, presents some preliminary experiences in implementing small devices using those libraries, and discusses trade-offs involving different types of approaches. | ||||||||||||||||
| draft-aldrin-trill-data-center-interconnect-00.txt | |||||||||||||||||
| TRILL Data Center Interconnect | |||||||||||||||||
|
This document presents a solution suite for TRILL data center sites to be connected over WAN networks. TRILL protocol is primarily designed to work within intra-data centers. Connecting different sites over WAN using overlay tunnel protocols is the primary method employed at present. Though this presents a simple mechanism to extend the LAN sites to be interconnected, it also brings in the problem of scalability for TRILL nicknames exchanged between sites, latency, duplication of traffic etc. This draft proposes a way to extend the TRILL sites without having to reveal the data of the LAN like customer MAC's or provide MAC's over the WAN, but to establish connections between various sites by extending routing protocol to exchange minimal information, thus reducing the information flow to the required sites only. Document also proposes BGP routing protocol extensions as an example to establish paths and information about the essential RBridges nicknames, over WAN networks like MPLS. | ||||||||||||||||
| draft-alexander-roll-mikey-lln-key-mgmt-03.txt | |||||||||||||||||
| Adapted Multimedia Internet KEYing (AMIKEY): An extension of Multimedia Internet KEYing (MIKEY) Methods for Generic LLN Environments | |||||||||||||||||
|
Multimedia Internet Keying (MIKEY) is a key management protocol used for real-time applications. As standardized within RFC3830 it defines four key distribution methods, including pre-shared keys, public-key encryption, and Diffie-Hellman key exchange, with allowances for ready protocol extension. A number of additional methods have been developed and continue to be built from the base protocol (see for example, RFC4442, RFC4563, RFC4650, RFC4738, RFC5410, RFC6043 and RFC6267. However, in spite of its extensibility and more general applicability, MIKEY and its related extensions have primarily focused on the support of the Secure Real-time Transport Protocol (SRTP). This document specifies a simple adaptation of the MIKEY specification to allow the base protocol and its various key management mode extensions to be readily applied in more general environments beyond the multimedia SRTP domain. In particular, the document defines a repurposing of the MIKEY multimedia crypto sessions structure and introduces a set of message extensions to the base specification to allow the MIKEY key management methods to be applied within Low-power and Lossy networks (LLNs) and other general constrained-device networks. | ||||||||||||||||
| draft-ali-ccamp-rc-objective-function-metric-bound-01.txt | |||||||||||||||||
| Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for signaling Objective Function and Metric Bound | |||||||||||||||||
|
When using GMPLS control plane, the ingress node may need to request remote node to perform route computation or expansion. In such cases, ingress node needs to convey the required objective function for the path computation algorithm to the remote node, so that the remote node can perform the route computation or expansion. Similarly, there are cases the ingress needs to indicate a TE metric bound for the loose segment which is expanded by the remote node(s). This document defines extensions to the RSVP-TE Protocol to allow an ingress node to request the required objective function for the path computation, as well as a metric bound to influence route computation decisions at a remote node(s). | ||||||||||||||||
| draft-ali-ccamp-rsvp-te-include-route-01.txt | |||||||||||||||||
| Include Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) | |||||||||||||||||
|
There are scenarios in which it is required that two or more LSPs or segments of LSPs follow same route in the network. This document specifies methods to communicate route inclusions along the loose hops during path setup using the Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) protocol. | ||||||||||||||||
| draft-ali-ccamp-te-metric-recording-01.txt | |||||||||||||||||
| Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path | |||||||||||||||||
|
There are many scenarios in which Traffic Engineering (TE) metrics such as cost, latency and latency variation associated with a Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched Path (LSP) are not available to the ingress and egress nodes. This draft provides extensions for the Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) for the support of the discovery of cost, latency and latency variation an LSP. | ||||||||||||||||
| draft-ali-ccamp-xro-lsp-subobject-01.txt | |||||||||||||||||
| Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) LSP Route Diversity using Exclude Routes | |||||||||||||||||
|
[RFC4874] specifies methods by which route exclusions may be communicated during RSVP-TE signaling in networks where precise explicit paths are not computed by the LSP ingress node. This document specifies signaling for additional route exclusions based on LSPs currently existing or expected to exist within the network. | ||||||||||||||||
| draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-07.txt | |||||||||||||||||
| Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment | |||||||||||||||||
|
Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not address many issues that come when a P2MP-TE LSP is signaled in inter-domain networks. Specifically, one of the issues in inter- domain networks is how to allow computation of a loosely routed P2MP-TE LSP such that it is re-merge free. Another issue is reoptimization of a P2MP-TE tree vs. reoptimization of an individual destination sub-LSP, as loosely routing domain border node is not aware of the reoptimization scope. This document provides a framework and required protocol extensions needed for establishing, controlling and reoptimizing P2MP MPLS and GMPLS TE LSPs in inter-domain networks. This document borrows inter-domain TE terminology from [RFC 4726], e.g., for the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). | ||||||||||||||||
| draft-allan-mpls-spme-smp-fmwk-00.txt | |||||||||||||||||
| A framework for the use of SPMEs for shared mesh protection | |||||||||||||||||
|
Shared mesh protection allows a set of diversely routed paths with diverse endpoints to collectively oversubcribe protection resources. Under normal conditions no single failure will result in the capacity of the associated protection resources to be exhausted. When multiple failures occur such that more than one path in the set of paths utilizing shared protection resources is affected, the necessity arises of pre-empting traffic on the basis of business priority rather than application priority. This memo describes the use of SPMEs and TC marking as a means of indicating business priority for shared mesh protection. | ||||||||||||||||
| draft-allan-mpls-unified-ic-req-frmwk-01.txt | |||||||||||||||||
| Requirements and Framework for Unified MPLS Sub-Network Interconnection | |||||||||||||||||
|
The definition of a transport profile for MPLS means that MPLS network architectures will emerge that combines both managed and control plane driven MPLS sub-networks and requires interconnection of same to achieve a unified MPLS architecture. This document generalizes the problem of sub-network interconnect, discusses issues in general and suggests ways forward. | ||||||||||||||||
| draft-allen-dispatch-imei-urn-as-instanceid-05.txt | |||||||||||||||||
| Using the International Mobile station Equipment Identity(IMEI)URN as an Instance ID | |||||||||||||||||
|
This specification defines how the Uniform Resource Name namespace reserved for GSMA (Global Sstandard for Mobiles 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." | ||||||||||||||||
| draft-allman-tcpm-rto-consider-01.txt | |||||||||||||||||
| Retransmission Timeout Considerations | |||||||||||||||||
|
This document provides for high-level guidance for retransmission timeout schemes appropriate for general use in the Internet. Terminology | ||||||||||||||||
| draft-alto-caching-subscription-00.txt | |||||||||||||||||
| ALTO Caching and Subscription | |||||||||||||||||
|
The specification of the ALTO protocol uses map based approaches assuming that the information provided is static for a longer period of time. But in some cases network operators reallocate IP subnets from time to time which in turn changes the mapping partitions[I- D.ietf-alto-deployments]. Since the ALTO clients are unaware of the map information changes, clients need to query the servers for every service request and many such requests are redundant because the information was not changed. The purpose of this memo is to provide two mechanisms which will help the ALTO clients to be informed of the map information changes. a) ALTO clients cache the map information and the servers provide the expiration time for invalidation. b) ALTO clients can subscribe for event notifications from the server | ||||||||||||||||
| draft-alvestrand-rmcat-remb-00.txt | |||||||||||||||||
| RTCP message for Receiver Estimated Maximum Bitrate | |||||||||||||||||
|
This document proposes an RTCP message for use in experimentally- deployed congestion control algorithms for RTP-based media flows. | ||||||||||||||||
| draft-alvestrand-rtcweb-congestion-02.txt | |||||||||||||||||
| A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web | |||||||||||||||||
|
This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. | ||||||||||||||||
| draft-alvestrand-rtcweb-msid-01.txt | |||||||||||||||||
| Signalling Media Stream ID in the Session Description Protocol | |||||||||||||||||
|
This document specifies how the association between the RTP concept of SSRC and the WebRTC concept of "media stream" / "media stream track" is carried using SDP signalling. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. | ||||||||||||||||
| draft-alvestrand-rtcweb-resolution-00.txt | |||||||||||||||||
| RTCWEB Resolution Negotiation | |||||||||||||||||
|
This draft offers a proposal for a fragment of the SDP usage rules for RTCWEB: Requirements for supporting resolution negotiation. It proposes to use SDP both for initial and within-call resolution configuration, and suggests that COP should be mentioned as an optional, not mandatory, mechanism. | ||||||||||||||||
| draft-alvestrand-rtp-sess-neutral-00.txt | |||||||||||||||||
| Why RTP Sessions Should Be Content Neutral | |||||||||||||||||
|
This document is not intended for publication as an RFC. It gives the underpinning arguments for why the idea that RTP sessions and MIME top level types are related is a deeply broken paradigm, and that we need to get away from it. These arguments are solely the opinion of the listed author. | ||||||||||||||||
| draft-an-savi-mib-02.txt | |||||||||||||||||
| Definition of Managed Objects for SAVI Protocol | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ananth-middisc-tcpopt-00.txt | |||||||||||||||||
| TCP option for transparent Middlebox discovery | |||||||||||||||||
|
This document describes a TCP option for use by middleboxes to facilitate transparent detection of other middleboxes along the path of the TCP connection during the connection initiation phase. The option has no effect if an appropriate middlebox is not present on the path. The TCP end hosts are unaware of this option and its usage is strictly for use by TCP middleboxes. Multiple vendors of WAN optimization products have used similar (but incompatible and proprietary) mechanisms since at least 2004. Those existing vendor systems use multiple TCP option code points, all of which are officially unassigned by IANA. The goal of this memo is to standardize a single TCP option code point for this functionality. This memo is the product of discussion among some of the vendors currently using incompatible proprietary TCP options for middlebox discovery. It is a non-goal of this memo to achieve interoperability of middlebox discovery between multiple vendors. It needs to be noted that an earlier document [I-D.knutsen-tcpm-middlebox-discovery], is re-written as the current document after agreement from multiple vendors. | ||||||||||||||||
| draft-ananth-tcpm-tcpoptext-00.txt | |||||||||||||||||
| TCP option space extension | |||||||||||||||||
|
The document goals are as follows: Firstly, this document summarizes the motivations for extending TCP option space. Secondly, It tries to summarize the various known issues that needs to be taken into account while extending the TCP option space. Thirdly, it briefly provides a short summary of the various TCP option space proposals that has been proposed so far. Some additional proposals which includes variations to the existing proposals are also presented. The goal of this document is to rejuvenate the discussions on this topic and eventually to converge on a scheme for extending TCP option space. | ||||||||||||||||
| draft-andrews-6man-force-fragmentation-01.txt | |||||||||||||||||
| Forcing Fragmentation of IPv6 Packets | |||||||||||||||||
|
Extend The Advanced Sockets API for IPv6 (RFC 3542) to provide a mechanism to force a Fragment header to be added to a packet. | ||||||||||||||||
| draft-andrews-dnsext-udp-fragmentation-01.txt | |||||||||||||||||
| DNS and UDP Fragmentation | |||||||||||||||||
|
This document provides advice to DNS developers about sending DNS UDP messages and Path MTU Discovery. | ||||||||||||||||
| draft-arias-noguchi-dnrd-objects-mapping-00.txt | |||||||||||||||||
| Domain Name Registration Data (DNRD) Objects Mapping | |||||||||||||||||
|
This document specifies the format and contents of Domain Name Registration Data (DNRD) Escrow deposits. Specified in Extensible Markup Language (XML), the mapping defines Registration Data Escrow (RDE) deposit syntax and semantics. | ||||||||||||||||
| draft-arias-noguchi-registry-data-escrow-03.txt | |||||||||||||||||
| Registry Data Escrow Specification | |||||||||||||||||
|
This document specifies the format and contents of Data Escrow deposits targeted primarly for Domain Name Registries. However, the specification was designed to be independent of the underlying objects that are being escrowed, therefore it could be used for other than Domain Name Registries. | ||||||||||||||||
| draft-arkko-homenet-physical-standard-00.txt | |||||||||||||||||
| Minimum Requirements for Physical Layout of Home Networks | |||||||||||||||||
|
Support for network technology in buildings varies greatly depending on the age of the building, but the ease of building a home network is also highly dependent on the chosen wiring, power, and equipment space designs. As networking technology evolves at a fast pace, it is important to choose designs that are expected to be useful for a long time. While there are many cabling, equipment, and protocol standards, only limited standards exist for the physical network layout for new buildings. This memo sets a baseline requirements that new, single-family dwellings must at least satisfy in order to benefit from advances in networking technology. Standardizing network technology for buildings is a challenging task, however. This memo has been submitted for the home networking working group at the IETF as one forum that the authors were able to find that cares about the home network as a system. However, in general the IETF has expertise only on protocols, not on the physical medium. Advice is sought on what existing standards already address this problem, what standardization efforts may be under way in the world, and if work remains, what the right forum to discuss these matters might be. | ||||||||||||||||
| draft-arkko-iesg-crossarea-00.txt | |||||||||||||||||
| Experiences from Cross-Area Work at the IETF | |||||||||||||||||
|
This memo discusses the reasons for IETF work on topics that cross area boundaries. Such cross-area work presents challenges for the organization of the IETF as well as on how interested parties can participate the work. The memo also provides some suggestions on managing these challenges. | ||||||||||||||||
| draft-asaeda-multimob-pmip6-extension-10.txt | |||||||||||||||||
| Multicast Routing Optimization by PIM-SM with PMIPv6 | |||||||||||||||||
|
This document describes IP multicast routing optimization using PIM-SM in Proxy Mobile IPv6 (PMIPv6) environment. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol and act as PIM-SM routers. The proposed protocol optimization addresses the tunnel convergence problem and provides seamless handover. | ||||||||||||||||
| draft-asaeda-xrblock-rtcp-xr-synchronization-05.txt | |||||||||||||||||
| RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting | |||||||||||||||||
|
This document defines two RTCP XR Report Blocks and associated SDP parameters that allow the reporting of synchronization delay and offset metrics for use in a range of RTP applications. | ||||||||||||||||
| draft-asai-cross-domain-overlay-03.txt | |||||||||||||||||
| Considerations on the AS-Level Application-Layer Traffic Optimization | |||||||||||||||||
|
Application-layer or overlay routing has been applied to various distributed systems such as content delivery networks and live media streaming systems. The problems with these systems for the layer 3 network providers, such as Internet service providers, are that these systems utilize higher-cost network resources (e.g., transit links) from the viewpoint of the layer 3 network providers but the operators have difficulties in controlling and optimizing the traffic of these systems because these systems construct their own networks over the layer 3 network. The ALTO Working Group has worked on application- layer traffic optimization to fill the gaps in routing policies between the layer 3 network and applications by providing the underlay network topology and cost information to these systems. However, there are considerations on applying application-layer traffic optimization techniques to cross-domain traffic because the cost is assumed to be configured by each AS although ASes are autonomously operated. This document summarizes general problems with overlay networks and considerations on the AS-level application- layer traffic optimization from the viewpoint of inter-AS economics. The main concerns on the AS-level application-layer traffic optimization are unfair policy configuration between distinct administrative domains and asymmetric economic policies on transit links. The underlying problem inducing these concerns is that the economic policies between interconnected ASes are non-disclosure due to commercial contracts. This document also discusses the conceivable approaches to solve the problems and considerations. | ||||||||||||||||
| draft-atlas-rtgwg-mrt-mc-arch-00.txt | |||||||||||||||||
| An Architecture for Multicast Protection Using Maximally Redundant Trees | |||||||||||||||||
|
Failure protection is desirable for multicast traffic, whether signaled via PIM or mLDP. Different mechanisms are suitable for different use-cases and deployment scenarios. This document describes the architecture for global protection (aka multicast live- live) and for local protection (aka fast-reroute). The general methods for global protection and local protection using alternate-trees are dependent upon the use of Maximally Redundant Trees. Local protection can also tunnel traffic in unicast tunnels to take advantage of the routing and fast-reroute mechanisms available for IP/LDP unicast destinations. The failures protected against are single link or node failures. While the basic architecture might support protection against shared risk group failures, algorithms to dynamically compute MRTs supporting this are for future study. | ||||||||||||||||
| draft-avasarala-dispatch-comm-div-notification-09.txt | |||||||||||||||||
| A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service | |||||||||||||||||
|
3GPP and TISPAN are defining the protocol specification for the Communication Diversion (CDIV) service using IP Multimedia (IM) Core Network (CN) subsystem supplementary service. As part of CDIV, a SIP based Event package framework is used for notifying users about diversions (re-directions or forwarding) of their incoming communication sessions. This document proposes a new SIP event package for allowing users to subscribe to and receive such notifications. Users can further define filters to control the rate and content of such notifications. The proposed event package is applicable to the CDIV supplementary service in IMS and may not be applicable to the general internet. . | ||||||||||||||||
| draft-ayar-transparent-sca-proxy-00.txt | |||||||||||||||||
| A Transparent Performance Enhancing Proxy Architecture To Enable TCP over Multiple Paths for Single-Homed Hosts | |||||||||||||||||
|
This draft complements the work of MPTCP by defining a TCP Splitter/ Combiner Architecture (SCA) that enables non-MPTCP-capable single- homed hosts to benefit from the multiple paths within Internet by means of performance enhancing proxies (PEPs) placed in the access networks. SCA Proxies (SCAPs) make use of multiple paths in a way which is completely transparent to end-hosts. Since the existence of the SCAPs is shielded from the TCP end-points, they can be deployed in the Internet as well as on the end-systems. | ||||||||||||||||
| draft-baccelli-manet-multihop-communication-01.txt | |||||||||||||||||
| Multi-hop Ad Hoc Wireless Communication | |||||||||||||||||
|
This document describes some characteristics of communication between nodes in a multi-hop ad hoc wireless network. These are not requirements in the sense usually understood as applying to formulation of a requirements document. Nevertheless, protocol engineers and system analysts involved with designing solutions for ad hoc networks must maintain awareness of these characteristics. | ||||||||||||||||
| draft-badra-netconf-rfc5539bis-02.txt | |||||||||||||||||
| NETCONF 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 NETCONF exchanges. This document obsoletes RFC 5539. | ||||||||||||||||
| draft-badra-tls-ciphersuite-identity-protection-00.txt | |||||||||||||||||
| Credential Protection Ciphersuites for Transport Layer Security (TLS) | |||||||||||||||||
|
This document defines a set of cipher suites to add client credential protection to the Transport Layer Security (TLS) protocol. By negotiating one of those ciphersuites, the TLS clients will be able to determine for themselves when, how, to what extent and for what purpose information about them is communicated to others. The ciphersuites defined in this document can be used only when public key certificates are used in the client authentication process. | ||||||||||||||||
| draft-badra-tls-identity-protection-02.txt | |||||||||||||||||
| SCSV for TLS Client Credential Protection | |||||||||||||||||
|
This document defines a special Signaling Cipher Suite Value (SCSV) "TLS_IDENTITY_PROTECTION_SCSV" to add client credential protection to the TLS protocol. | ||||||||||||||||
| draft-bajko-pripaddrassign-04.txt | |||||||||||||||||
| Port Restricted IP Address Assignment | |||||||||||||||||
|
This document defines an IPv4 DHCP Option and related behaviours to allocate the same IPv4 address to multiple nodes by sharing the available port space among them. The two sub-options defined in this document specify random port allocation to nodes in order to maximize the entropy of port randomization. | ||||||||||||||||
| draft-baker-homenet-prefix-assignment-01.txt | |||||||||||||||||
| IPv6 Prefix Assignment in Small Networks | |||||||||||||||||
|
It is necessary to allocate prefixes in small networks, which include residential and Small Office/Home Office (SOHO) networks in a manner that minimizes or eliminates manual configuration. This note suggests an approach. | ||||||||||||||||
| draft-baker-opsawg-firewalls-00.txt | |||||||||||||||||
| On Firewalls in Internet Security | |||||||||||||||||
|
There is an ongoing discussion regarding the place of firewalls in security. This note is intended to capture and try to make sense out of it. | ||||||||||||||||
| draft-baker-opsec-passive-ip-address-00.txt | |||||||||||||||||
| Passive IP Addresses | |||||||||||||||||
|
This note suggests an approach to minimizing the attack surface of the network elements - routers, switches, and middleware - of a network. | ||||||||||||||||
| draft-baker-pcp-nptv6-search-00.txt | |||||||||||||||||
| Using PCP to Find an External Address in an NPTv6 Network | |||||||||||||||||
|
This note describes an approach to finding the set of External Addresses associated with an Internal Address. Requirements | ||||||||||||||||
| draft-bakht-maoddp-01.txt | |||||||||||||||||
| Mobile Ad-hoc On-Demand Data Delivery Protocol (MAODDP) | |||||||||||||||||
|
Routing in mobile ad-hoc network is achieved through the mutual cooperation of mobile devices that form routes in between two mobile nodes.It is one of the challenging issues in mobile ad-hoc network [1]. The current protocols for an ad-hoc network can generally be categorized into two groups i.e. pro-active and re-active[15,16,17,18]. Pro-active protocols by continuously evaluating the known and attempting to discover new routes. These protocols try to maintain the most up-to-date view of the network[2]. This allows them to efficiently forward packets as the route is known in advanced [14]. In contrast reactive protocols determine the route only when require [3, 5, 6]. Mobile Ad-hoc On Demand Data Delivery protocol (MAODDP) establishes route on demand and delivers the data at the same time one after the other [22].MAODDP support both unicast and multicast routing. It is designed to minimize reaction to topological changes. In order to ensure the freshness of route MAODDP uses combination of sequence numbers and broadcast ID. MAODDP is loop-free, self-starting protocol whic can scales to different size of networks. MAODDP offers quick adaptation to the dynamic link conditions and determines routes to the destinations on demand. | ||||||||||||||||
| draft-bakker-sipping-3gpp-ims-xml-body-handling-08.txt | |||||||||||||||||
| Specification of 3GPP IM CN Subsystem XML body handling | |||||||||||||||||
|
This document registers new disposition-types for the Content- Disposition header field that apply to the application/3gpp-ims+xml body (part) used by 3GPP. The applicability of these content- disposition values are limited to 3GPP IMS. The application/ 3gpp-ims+xml body (part) has the following three distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), (2) for delivering user profile specific information from the SIP registrar to an Application Server, and (3) for causing a UAC to attempt to re-register with the IMS. | ||||||||||||||||
| draft-balaji-opsawg-vxlan-vm-topo-discovery-01.txt | |||||||||||||||||
| VM to VTEP maps topology discovery in VXLAN based data centers | |||||||||||||||||
|
This document proposes a method by which in a VXLAN environment the ARP tables of each VTEP having an active VM belonging to a particular tenant where such active VMs are distributed amongst several VTEPs in a data center or across data centers are walked through and the collation of the location of such active VMs and the VTEPs they are located in is found for management and network resource planning purposes. | ||||||||||||||||
| draft-balaji-trill-over-ip-multi-level-05.txt | |||||||||||||||||
| Connecting Disparate Data Center/PBB/Campus TRILL sites using BGP | |||||||||||||||||
|
There is a need to connect (a) TRILL based data centers or (b) TRILL based networks which provide Provider Backbone like functionalities or (c) Campus TRILL based networks over the WAN using one or more ISPs that provide regular IP+GRE or IP+MPLS transport. A few solutions have been proposed as in [1] in the recent past that have not looked at the PB-like functionality. These solutions have not dealt with the details as to how these services could be provided such that multiple TRILL sites can be inter-connected with issues like nick-name collisons for unicast and multicast being taken care of. It has been found that with extensions to BGP the problem statement which we will define below can be handled. Both control plane and data plane operations can be driven into the solution to make it seamlessly look at the entire set of TRILL sites as a single entity which then can be viewed as one single Layer 2 cloud. MAC moves across TRILL sites and within TRILL sites can be realized. This document / proposal envisions the use of BGP-MAC-VPN vrfs both at the IP cloud PE devices and at the peripheral PEs within a TRILL site providing Provider Backbone like functionality. We deal in depth with the control plane and data plane particulars for unicast and multicast with nick-name election being taken care of as part of the solution. | ||||||||||||||||
| draft-balaji-trill-te-multi-site-interconnect-00.txt | |||||||||||||||||
| Interconnecting multiple TRILL sites deploying Traffic Engineering | |||||||||||||||||
|
This document specifies the control plane procedures to support Traffic Engineering (TE) across TRILL sites where such sites are interconnected using [1] with the help of a Layer 3 core running IP+GRE or IP+MPLS. Traffic Engineering permits usage of a set of links that possess a certain characteristic like specified bandwidth, cost or even MTU. This draft aims at addressing how unicast frames travelling from one TRILL site to another across a Layer 3 core that supports IP+GRE and/or IP+MPLS can make use of the TE calculated paths in the sending site as well as the receiving site where such TE paths are pre-computed in both sites and need a mechanism to inter- link them together. | ||||||||||||||||
| draft-balls-ccamp-relax-loop-check-01.txt | |||||||||||||||||
| Relaxing RSVP Loop Checking | |||||||||||||||||
|
This specification relaxes the rules governing loop checking within RSVP. These were originally defined in [RFC3209] and are too strict for the requirements of today's data planes. | ||||||||||||||||
| draft-bao-pwe3-pw-transfer-03.txt | |||||||||||||||||
| LDP Extensions for Pseudo Wire (PW) Transfer in an MPLS-TP Network | |||||||||||||||||
|
As defined in [RFC5654] MPLS-TP transport path includes LSP and PW. And the possibility of transferring the ownership and control of an existing and in-use path between the management plane and the control plane, without actually affecting data plane traffic being carried over it, is a valuable option for carrier. [RFC5493] and [RFC5852] describe the LSP transfer. This memo gives the requirement and LDP extensions for PW transfer in an MPLS-TP network. | ||||||||||||||||
| draft-barnes-atoca-meta-02.txt | |||||||||||||||||
| Alert Metadata Protocol (AMP) | |||||||||||||||||
|
Recipients of emergency alerts need to discover information about local alert distribution servers, and to register contact points where they can receive alerts. This document defines a mechanism for IP networks to advertise a local alert server, and a protocol that devices on the network can use to retrieve local information and register information about themselves. Please send feedback to the atoca@ietf.org mailing list. | ||||||||||||||||
| draft-barnes-healthy-food-05.txt | |||||||||||||||||
| Healthy Food and Special Dietary Requirements for IETF meetings | |||||||||||||||||
|
This document describes the basic requirements for food for folks that attend IETF meetings require special diets, as well as those that prefer to eat healthy. While, the variety of special diets is quite broad, the most general categories are described. There can be controversy as to what constitutes healthy eating, but there are some common, generally available foods that comprise the basis for healthy eating and special diets. This document provides some recommendations to meeting planners, as well as participants, in handling these requirements. | ||||||||||||||||
| draft-barnes-jose-use-cases-00.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-barnes-sipcore-rfc4244bis-callflows-03.txt | |||||||||||||||||
| Session Initiation Protocol (SIP) History-Info Header Call Flow Examples | |||||||||||||||||
|
This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. | ||||||||||||||||
| draft-bashandy-bgp-edge-node-frr-02.txt | |||||||||||||||||
| Scalable BGP FRR Protection against Edge Node Failure | |||||||||||||||||
|
Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it is desirable for a core router "P" carrying traffic to the failed edge router PEi to immediately restore traffic by re-tunneling packets originally tunneled to PEi and destined to the prefix P/m to one of the other edge routers that advertised P/m, say PEj, until BGP re-converges. In doing so, it is highly desirable to keep the core BGP-free while not imposing restrictions on external connectivity. Thus (1) a core router should not be required to learn any BGP prefix, (2) the size of the forwarding and routing tables in the core routers should be independent of the number of BGP prefixes,(3) there should be no special router (or group of routers) that handles restoring traffic or the need for one router to store the forwarding table of another router, (4) re-routing traffic without waiting for re-convergence must not cause loops, and (4) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (6) the repairing core router must swap the label stack advertised by the failed edge router PEi for the prefix P/m with the label stack advertised for the same prefix by the edge router PEj before re- tunneling the packet to PEj | ||||||||||||||||
| draft-bashandy-idr-bgp-repair-label-04.txt | |||||||||||||||||
| Scalable,Loop-Free BGP FRR using Repair Label | |||||||||||||||||
|
Consider a BGP free core scenario. Suppose the provider edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the PE router PEi loses connectivity to the primary path, it is desirable to immediately restore traffic by rerouting packets arriving from the core to PEi and destined to the prefix P/m to one of the other PE routers that advertised P/m, say PEj, until BGP re-converges. However if the loss of connectivity of PEi to the primary path also resulted in the loss of connectivity between PEj and CEj, rerouting a packet before the control plane converges may result in a loop. In this document, we propose using a repair label for traffic restoration while avoiding loops. We propose advertising the "repair" label through BGP. | ||||||||||||||||
| draft-bashandy-isis-bgp-edge-node-frr-00.txt | |||||||||||||||||
| IS-IS Extension for BGP FRR Protection against Edge Node Failure | |||||||||||||||||
|
Consider a BGP free core scenario where traffic is tunneled between edge routers. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it desirable for a core router "P" that is carrying traffic to the failed edge router PEi to immediately restore traffic by re- routing packets originally tunneled to PEi and destined to the prefix P/m to one of the other edge routers that advertised P/m, say PEj, until BGP re-converges. If the packets originally flowing to the failed edge router PEi are labeled, then the repairing core router P router must swap the label advertised by the failed edge router PEi for the prefix P/m with the label advertised for the same prefix by the edge router PEj before re-routing the packet through an LSP terminating PEj. The document proposes an extension to IS-IS protocol to inform core routers about the repair edge router PEj and, for labeled packets, the label that needs to be pushed/swapped before sending the packet into the tunnel terminating on PEj | ||||||||||||||||
| draft-bashandy-mpls-ldp-bgp-frr-00.txt | |||||||||||||||||
| LDP Extension for FRR Edge Node Protection in BGP-Free LDP Core | |||||||||||||||||
|
Consider a BGP free core scenario with LDP running in the core. Suppose the edge BGP speakers PE1 and PE2 know about a prefix P/m via the external routers CE1 and CE2. If the edge LSR PE1 crashes or becomes totally disconnected from the core, it is desirable for a core LSR "P", that is carrying traffic to the failed edge LSR PE1, to immediately restore traffic by re-routing packets destined to the prefix P/m from the LSP terminating on PE1 to be forwarded over the LSP terminating on PE2, until BGP reconverges. If the packets originally flowing to the failed edge LSR PE1 are BGP labeled, then the repairing core LSR P must swap the label (corresponding to prefix P/m) advertised by the failed edge LSR PE1 with the label advertised for the same prefix by the edge LSR PE2 before re-routing the packets through an LSP terminating on PE2. To implement BGP edge node protection in a BGP-free LDP core, this document proposes an extension to LDP. This extension allows an LDP speaker running on a Edge LSR Node (e.g. PE1) to inform the LDP speakers running on core LSRs about the "Repair" edge LSR (e.g. PE2), as well as Repair LSR's label for prefix P/m, if any. | ||||||||||||||||
| draft-bcd-6man-ntp-server-ra-opt-00.txt | |||||||||||||||||
| IPv6 Router Advertisement Option for NTP Server Configuration | |||||||||||||||||
|
This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise Network Time Protocol version 4 or greater server location information to IPv6 hosts. | ||||||||||||||||
| draft-bcheng-r2ri-framework-00.txt | |||||||||||||||||
| Radio to Router Interface Framework and Requirements | |||||||||||||||||
|
In highly dynamic, heterogeneous radio MANET environments where links are constantly changing, standardizing information exchange between the radio and router such that routers can make informed routing decision based on link layer information over heterogeneous link types becomes a key area to address. This document defines the basic framework for radio-to-router interface communications as well as requirements and considerations for evaluating radio-to-router interface technologies for use in MANETs. | ||||||||||||||||
| draft-beauchamp-private-wire-04.txt | |||||||||||||||||
| A Session Initiation Protocol (SIP) INFO package for Private Wire | |||||||||||||||||
|
Application level data exchanged using the SIP INFO method are supported and documented in specifications known as 'INFO Packages'. This document defines functionality associated with Session Initiation Protocol (SIP) Private Wire functionality and creates an 'INFO Package' for carrying such application level data. | ||||||||||||||||
| draft-becker-core-coap-sms-gprs-01.txt | |||||||||||||||||
| Transport of CoAP over SMS,USSD and GPRS | |||||||||||||||||
|
The Short Message Service (SMS) and Unstructured Supplementary Service Data (USSD) of mobile cellular networks is frequently used in Machine-To-Machine (M2M) communications, such as for telematic devices. The service offers small packet sizes and high delays just as other typical low-power and lossy networks (LLNs), i.e. 6LoWPANs. The design of the Constrained Application Protocol (CoAP), that took the limitations of LLNs into account, is thus also applicable to telematic M2M devices. The adaptation of CoAP to the SMS or USSD transport mechanisms and the combination with IP transported over cellular networks is described in this document. | ||||||||||||||||
| draft-beeram-ccamp-gmpls-uni-bcp-01.txt | |||||||||||||||||
| GMPLS-UNI BCP | |||||||||||||||||
|
This document pools together the best current practices that are being used to apply the GMPLS Overlay model at the User-Network Interface (UNI) reference point (as defined in [G.8080]) | ||||||||||||||||
| draft-begen-avtcore-rtp-duplication-01.txt | |||||||||||||||||
| Duplicating RTP Streams | |||||||||||||||||
|
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 explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP media streams, or RTP Control Protocol (RTCP) rules. | ||||||||||||||||
| draft-begen-mmusic-redundancy-grouping-03.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-begen-mmusic-temporal-interleaving-04.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-behringer-lla-only-00.txt | |||||||||||||||||
| Using Only Link-Local Address in Network Core | |||||||||||||||||
|
This document proposes to use only IPv6 link-local addresses on infrastructure links between routers, wherever possible. It discusses the advantages and disadvantages of this approach to aide the decision process for a given network, | ||||||||||||||||
| draft-bellis-dnsext-multi-qtypes-01.txt | |||||||||||||||||
| Title | |||||||||||||||||
|
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. | ||||||||||||||||
| draft-bellis-geopriv-flow-identity-01.txt | |||||||||||||||||
| Flow Identity Extension for HELD | |||||||||||||||||
|
Identity Extensions using an IP address and port number to request a location based on an individual packet flow have been previously specified by the GEOPRIV Working Group. However certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request. This document specifieds a Flow Identity Extension for the HTTP- Enabled Location Delivery (HELD) Protocol to support this requirement. | ||||||||||||||||
| draft-bellovin-hpw-01.txt | |||||||||||||||||
| Hashed Password Exchange | |||||||||||||||||
|
Many systems (e.g., cryptographic protocols relying on symmetric cryptography) require that plaintext passwords be stored. Given how often people reuse passwords on different systems, this poses a very serious risk if a single machine is compromised. We propose a scheme to derive passwords limited to a single machine from a typed password, and explain how a protocol definition can specify this scheme. | ||||||||||||||||
| draft-benjamin-extendedcallbackinfo-02.txt | |||||||||||||||||
| AFS Callback Extensions (Draft 14) | |||||||||||||||||
|
AFS cache-control strategy is callback (invalidate) based. The AFS callback design allows a client to know when an object it has cached is no longer consistent, but the callback notification message itself provides no specific information about the triggering event. This is a protocol inefficiency, as in several scenarios it results in unnecessary round-trips to file servers to verify file status information, file access information, or to fetch file data which has not changed. We propose an extension of the callback mechanism to provide information about the event(s) triggering a callback, in the payload of the callback notification message itself. The proposed mechanism eliminates most or all unnecessary round-trips imposed by the current callback mechanism, and simultaneously allows AFS implementations to (efficiently) provide correct semantics in several scenarios involving multiple writers (ie, where AFS currently provides incorrect semantics). | ||||||||||||||||
| draft-berger-ccamp-swcaps-update-01.txt | |||||||||||||||||
| Revised Definition of The GMPLS Switching Capability and Type Fields | |||||||||||||||||
|
GMPLS provides control for multiple switching technologies, and hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate switching technology type. These values are carried in routing in the Switching Capability field, and in signaling in the Switching Type field. While the values using in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates any document that uses the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. | ||||||||||||||||
| draft-bernardini-ppetp-03.txt | |||||||||||||||||
| Peer-to-Peer Epi-Transport Protocol | |||||||||||||||||
|
This document describes PPETP (Peer-to-Peer Epi-Transport Protocol) a peer-to-peer distribution protocol suited for streaming applications over networks made of heterogeneous nodes. | ||||||||||||||||
| draft-bernardos-dmm-distributed-anchoring-00.txt | |||||||||||||||||
| PMIPv6-based distributed anchoring | |||||||||||||||||
|
Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centralized deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (as Mobile IPv6), among others. This document follows the former approach, and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called distributed gateway). The distributed gateway is an enhanced access router which is also able to operate as local mobility anchor or mobility access gateway, on a per prefix basis. The draft focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. This draft introduces the concept of distributed logical interface (at the distributed gateway), which is a software construct that allows to easily hide the change of anchor from the mobile node. Additionally, the draft describes how to provide session continuity in inter-domain scenarios in which dynamic tunneling or signaling between distributed gateways from different operators is not allowed. | ||||||||||||||||
| draft-bernardos-dmm-pmip-01.txt | |||||||||||||||||
| A PMIPv6-based solution for Distributed Mobility Management | |||||||||||||||||
|
The number of mobile users and their traffic demand is expected to be ever-increasing in future years, and this growth can represent a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy Mobile IPv6. For this reason it has been waved a need for distributed and dynamic mobility management approaches, with the objective of reducing operators' burdens, evolving to a cheaper and more efficient architecture. This draft describes multiple solutions for network-based distributed mobility management inspired by the well known Proxy Mobile IPv6. | ||||||||||||||||
| draft-bernardos-netext-pmipv6-nemo-ps-02.txt | |||||||||||||||||
| PMIPv6 and Network Mobility Problem Statement | |||||||||||||||||
|
The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. Current PMIPv6 specification does only support the movement of hosts within the localized mobility domain. A mobile network (commonly referred to as a NEMO, NEtwork that MOves) can also benefit from the network-based localized mobility support provided by PMIPv6 [I-D.ietf-netext-pd-pmip], but with some limitations. This I-D describes what can be done with current standardized protocols, and describes the problem statement of fully supporting network mobility in Proxy Mobile IPv6. | ||||||||||||||||
| draft-bernstein-alto-large-bandwidth-cases-01.txt | |||||||||||||||||
| Use Cases for High Bandwidth Query and Control of Core Networks | |||||||||||||||||
|
This draft describes two generic use-cases that illustrate application layer traffic optimization applied to high bandwidth core networks. The type of information and interactions needed to perform various optimizations is described. In addition, extensions to the existing ALTO protocol are suggested that provide this functionality. | ||||||||||||||||
| draft-bertrand-cdni-experiments-02.txt | |||||||||||||||||
| Content Distribution Network Interconnection (CDNI) Experiments | |||||||||||||||||
|
This document reports studies and related experiments on CDN interconnection performed by France Telecom-Orange Labs. The document summarizes implications of CDN interconnection to CDN service providers and lessons learned through CDNI experiments. The main purpose of the experiments was to test the interconnection of CDN solutions from two vendors (namely, Cisco and Verivue) and to identify the gaps and needs for standardization work for CDN interconnection. | ||||||||||||||||
| draft-bertrand-cdni-footprint-discovery-00.txt | |||||||||||||||||
| CDN Footprint Discovery | |||||||||||||||||
|
Interconnected CDNs need to exchange information on the set of end- users to which they can deliver content. This information is commonly referred to as "CDN Footprint". This memo presents use cases for CDN Footprint Discovery in CDNI. It provides a survey of existing work on the subject and a set of additional requirements for controlling the exchange of Footprint information. | ||||||||||||||||
| draft-bertrand-cdni-logging-00.txt | |||||||||||||||||
| CDNI Logging Interface | |||||||||||||||||
|
This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN). It introduces a framework, an architecture design and a set of new requirements. Then it drafts an information model. | ||||||||||||||||
| draft-bhandari-dhc-class-based-prefix-01.txt | |||||||||||||||||
| DHCPv6 class based prefix | |||||||||||||||||
|
DHCPv6 defines class based allocation of IA_NA and IA_TA IPv6 addresses. This document extends DHCPv6 prefix delegation with class based prefix allocation. It defines a new prefix class option to classify a prefix. It defines the behavior of a DHCPv6 client requesting a prefix to include the class of the prefix to be allocated and the DHCPv6 server behavior to select and offer a prefix from a given class. It discusses how IA_NA can be requested and assigned from a specific prefix class. | ||||||||||||||||
| draft-bhargav-l3vpn-inter-provider-optcsec-03.txt | |||||||||||||||||
| Preventing spoofing attacks in BGP-MPLS-VPN Inter-Provider Model-C | |||||||||||||||||
|
In certain models of inter-provider Multi-Protocol-Label-Switching based Virtual Private Networks (MPLS-VPNs), spoofing attacks against VPN sites is a key concern. Unidirectional attacks towards VPN sites can compromise servers at the VPN sites and cause Denial-of-Service (DoS) situations. Currently, the inner labels associated with VPN sites are not encrypted during transmission. The Provider Edge (PE) router at the end to which the VPN customer is attached accepts any data packet with a valid label. This enables a man-in-the-middle attacker to spoof a packet to a specific site of a VPN. In this paper, we propose some secure techniques which provide security against such label-spoofing. These techniques ensure that an attacker would not be able to spoof labeled data packets. In order to make the proposed scheme robust, some additional steps are proposed over and above the initial steps specified. This makes the attacker to spend non-linear time to guess the right label for his unidirectional attacks to succeed. Our proposed technique can be applied to a specific type of inter-provider Border Gateway Protocol(BGP) based MPLS VPN and other existing variant where Multi-Protocol exterior- BGP (MP-eBGP) multi-hop is used. In future, if any other variant is proposed to use MP-eBGP multi-hop, our scheme can be used to protect against spoofing attacks. | ||||||||||||||||
| draft-bhatia-ipsecme-avoiding-ah-00.txt | |||||||||||||||||
| Avoiding Authentication Header (AH) | |||||||||||||||||
|
This document recommends retiring Authentication Header (AH) and discusses the reasons for doing so. It recommends that AH must not be used for new applications and protocols, since Encapsulating Security Payload (ESP) using NULL encryption algorithm provides the same level of security in most real deployments. | ||||||||||||||||
| draft-bhatia-moving-ah-to-historic-00.txt | |||||||||||||||||
| Moving Authentication Header (AH) to Historic | |||||||||||||||||
|
This document recommends retiring Authentication Header (AH) and discusses the reasons for doing so. It recommends moving RFC 4302 to Historic status. | ||||||||||||||||
| draft-bhatia-zhang-karp-bfd-analysis-02.txt | |||||||||||||||||
| Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide | |||||||||||||||||
|
This document analyzes the Bidirectional Forwarding Detection protocol (BFD) according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide. | ||||||||||||||||
| draft-bhatia-zhang-pim-auth-extension-01.txt | |||||||||||||||||
| In-Band Authentication Extension for Protocol Independent Multicast (PIM) | |||||||||||||||||
|
Existing security mechanisms for the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol mandates to use IPsec to provide message authenticity and integrity. This draft proposes an embedded authentication mechanism to facilitate data origin authentication and integrity verification for PIM packets in the cases where IPsec is not applied. | ||||||||||||||||
| draft-bhh-mpls-tp-oam-y1731-08.txt | |||||||||||||||||
| MPLS-TP OAM based on Y.1731 | |||||||||||||||||
|
This document describes methods to leverage Y.1731 [2] Protocol Data Units (PDU) and procedures (state machines) to provide a set of Operation, Administration, and Maintenance (OAM) mechanisms that meets the MPLS Transport Profile (MPLS-TP) OAM requirements as defined in [8]. In particular, this document describes the MPLS-TP technology specific encapsulation mechanisms to carry these OAM PDUs within MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP networks. | ||||||||||||||||
| draft-bi-dhc-sec-option-01.txt | |||||||||||||||||
| Security option extensions for DHCPv4 | |||||||||||||||||
|
This document defines a new option that can be used by DHCP servers to exchange with DHCP clients specific security configuration information. This new option defines a standard parameter format and code so that there will be no ambiguity in interoperating the information being exchanged and that there will be no issues related to interoperability. It is an option definition extension for DHCPv4 which should be included in RFC 2132. | ||||||||||||||||
| draft-bi-savi-problem-03.txt | |||||||||||||||||
| 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 techniques for source address validation beyond the first hop (SAVI-BF) may be needed to complement SAVI. In the document, we analyze the problems of the current SAVI-BF technique, and discuss the directions we can explore to improve SAVI-BF. | ||||||||||||||||
| draft-bi-savi-wlan-02.txt | |||||||||||||||||
| A SAVI solution for WLAN | |||||||||||||||||
|
This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP to bind IP address with MAC address, and relies on the security of MAC address guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of mapping entries when hosts move from one access point to another. | ||||||||||||||||
| draft-bitar-datacenter-vpn-applicability-02.txt | |||||||||||||||||
| Cloud Networking: Framework and VPN Applicability | |||||||||||||||||
|
Cloud Computing has been attracting a lot of attention from the networking industry. Some of the most publicized requirements are related to the evolution of the Cloud Networking Infrastructure to accommodate a large number of tenants, efficient network utilization, scalable loop avoidance, and Virtual Machine Mobility. This draft describes a framework for cloud networking, highlighting the applicability of existing work in various IETF Working Groups (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working Groups) to cloud networking, and the gaps and problems that need to be further addressed. That is, the goal is to understand what may be re-used from the current protocols and call out requirements specific to the Cloud space that need to be addressed by new standardization work with proposed solutions in certain cases. | ||||||||||||||||
| draft-bjorklund-netmod-snmp-cfg-02.txt | |||||||||||||||||
| A YANG Data Model for SNMP Configuration | |||||||||||||||||
|
This document defines a collection of YANG definitions for configuring SNMP engines. | ||||||||||||||||
| draft-bl-nvo3-dataplane-requirements-00.txt | |||||||||||||||||
| NVO3 Data Plane Requirements | |||||||||||||||||
|
Several IETF drafts relate to the use of overlay networks to support large scale virtual data centers. This draft provides a list of data plane requirements for Network Virtualization over L3 (NVO3) that have to be addressed in solutions documents. | ||||||||||||||||
| draft-blake-nptv6-icmp-02.txt | |||||||||||||||||
| ICMP Handling in IPv6-to-IPv6 Network Prefix Translation | |||||||||||||||||
|
NPTv6 is a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT without some of that mechanism's drawbacks. NPTv6 is intended to be deployed in environments where a host might not know its "external" network prefix(es). In such an environment, a NPTv6 device must also translate network prefixes present in in-bound and out-bound ICMPv6 error message payloads. This document describes the required processing of ICMPv6 error messages. | ||||||||||||||||
| draft-blanchet-dtnrg-bp-application-framework-01.txt | |||||||||||||||||
| Delay-Tolerant Networking (DTN) Bundle Protocol Application Framework | |||||||||||||||||
|
The current Bundle Protocol specifications define the syntax of service identifiers but do not identify how to make them interoperable. For example, there are currently no way to map a service identifier to a specific Bundle payload format for an application agent. This document proposes an application framework enabling interoperable implementations and deployments of the Bundle Protocol. It also creates a service identifier registry for the Bundle Protocol. | ||||||||||||||||
| draft-bonica-v6-multihome-03.txt | |||||||||||||||||
| Multihoming with IPv6-to-IPv6 Network Prefix Translation (NPTv6) | |||||||||||||||||
|
RFC 6296 introduces IPv6-to-IPv6 Network Prefix Translation (NPTv6). By deploying NPTv6, a site can achieve addressing independence without contributing to excessive routing table growth. Section 2.4 of RFC 6296 proposes an NPTv6 architecture for sites that are homed to multiple upstream providers. By deploying the proposed architecture, a multihomed site can achieve access redundancy and load balancing, in addition to addressing independence. This memo proposes an alternative NPTv6 architecture for hosts that are homed to multiple upstream providers. The architecture described herein provides transport-layer survivability, in addition to the benefits mentioned above. In order to provide transport-layer survivability, the architecture described herein requires a small amount of additional configuration. This memo updates RFC 6296. | ||||||||||||||||
| draft-bormann-6lowpan-ghc-04.txt | |||||||||||||||||
| 6LoWPAN Generic Compression of Headers and Header-like Payloads | |||||||||||||||||
|
This short I-D provides a simple addition to 6LoWPAN Header Compression that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each new such header or header-like payload. | ||||||||||||||||
| draft-bormann-6lowpan-roadmap-01.txt | |||||||||||||||||
| 6LoWPAN Roadmap and Implementation Guide | |||||||||||||||||
|
6LoWPAN is defined in RFC 4944 in conjunction with a number of specifications that are currently nearing completion. The entirety of these specifications may be hard 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 attempts 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. The current version -01 of this document is an early draft that is intended to spark the further collection of relevant information. | ||||||||||||||||
| draft-bormann-coap-misc-16.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-bormann-core-links-json-00.txt | |||||||||||||||||
| Representing CoRE Link Collections in JSON | |||||||||||||||||
|
Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (I-D.ietf-core-link-format). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON format (RFC4627). This specification defines a common format for representing Web links in JSON format. | ||||||||||||||||
| draft-bormann-core-roadmap-01.txt | |||||||||||||||||
| 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. The current version -00 of this document is an early draft that is intended to spark the further collection of relevant information. | ||||||||||||||||
| draft-bormann-core-simple-server-discovery-01.txt | |||||||||||||||||
| CoRE Simple Server Discovery | |||||||||||||||||
|
CoRE defines a mechanism for resource discovery based on Web linking. Many applications also need a simple form of discovery for the servers carrying these resources. This specification shows a simple way to extend the link-based resource discovery into a basic form of server discovery. The current version -01 of this document continues an initial draft that is intended to spark discussion. | ||||||||||||||||
| draft-bormann-intarea-alfi-00.txt | |||||||||||||||||
| Adaptation Layer Fragmentation Indication | |||||||||||||||||
|
IPv6 defines a minimum MTU of 1280 bytes. Many link layers are more limited in their choice of packet size. Typically, IP adaptation layers for these link layers define a segmentation or fragmentation scheme to transport larger IP packets in multiple link layer packets. Often, adaption layer fragmentation schemes reduce some performance metric, such as the packet delivery rate. Where application or transport protocols have a choice, it would therefore be desirable for them to know about any adaptation layer fragmentation that is going on, so they can choose packet sizes that minimize adaptation layer fragmentation. At the IP layer, fragmentation can be detected using a number of mechanisms used in Packetization Layer Path MTU Discovery [RFC4821]. However, adaptation later fragmentation schemes are often designed to be "transparent", i.e. there is no way at higher layers to find out they had to be employed (except maybe by elaborate measurement schemes targeting one of the impacted performance metrics; this approach does not appear to be viable) [WEI]. The present specification defines a mechanism for IPv6 adaptation layers to indicate the presence of adaptation layer fragmentation, as well as an indication of preferred packet sizes. The main objective of this version of the draft is to present a complete design in order to be able to gauge the complexity of the approach against the gains to be expected from implementing it. Comments are appreciated and should go to the intarea@ietf.org mailing list. | ||||||||||||||||
| draft-bormann-lwig-guidance-01.txt | |||||||||||||||||
| Guidance for Light-Weight Implementations of the Internet Protocol Suite | |||||||||||||||||
|
Implementation of Internet protocols on small devices benefits from light-weight implementation techniques, which are often not documented in an accessible way. This document provides a first outline of and some initial content for the Light-Weight Implementation Guidance document planned by the IETF working group LWIG. | ||||||||||||||||
| draft-boucadair-64-multicast-address-format-00.txt | |||||||||||||||||
| IPv4-Embedded IPv6 Multicast Address Format | |||||||||||||||||
|
This document specifies an extension to the IPv6 multicast addressing architecture to be used in the context of IPv4-IPv6 interconnection. In particular, this document defines an address format for IPv4- embedded IPv6 multicast addresses. This address format can be used for IPv4-IPv6 translation or encapsulation schemes. This document updates RFC4291. | ||||||||||||||||
| draft-boucadair-mmusic-altc-05.txt | |||||||||||||||||
| Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute | |||||||||||||||||
|
This document proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer. The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax. | ||||||||||||||||
| draft-boucadair-mmusic-ipv6-use-cases-00.txt | |||||||||||||||||
| Session Description Protocol (SDP) Alternate Connectivity (ALTC): Use Cases | |||||||||||||||||
|
This memo identifies a set of use cases which motivate the specification of Session Description Protocol (SDP) Alternate Connectivity (ALTC) attribute. These use cases are specific to IPv4/ IPv6 co-existence, IPv4/IPv6 interworking and IPv6 migration. Both IPv6-related unicast and multicast are covered. | ||||||||||||||||
| draft-boucadair-pcp-bittorrent-00.txt | |||||||||||||||||
| Behavior of BitTorrent service in PCP-enabled networks with Address Sharing | |||||||||||||||||
|
This document describes the behavior of BitTorrent service in the context of PCP-enabled address sharing functions. It provides an overview of the used testbed and main results of the tests that have been conducted in order to assess the limitations of an architecture based on shared IP addresses. | ||||||||||||||||
| draft-boucadair-pcp-extensions-03.txt | |||||||||||||||||
| Some Extensions to Port Control Protocol (PCP) | |||||||||||||||||
|
This document extends Port Control Protocol (PCP) with new functionalities. | ||||||||||||||||
| draft-boucadair-pcp-failure-03.txt | |||||||||||||||||
| Port Control Protocol (PCP) Failure Scenarios | |||||||||||||||||
|
This document identifies and analyzes several PCP failure scenarios. A procedure to retrieve the explicit dynamic mapping(s) from the PCP Server is proposed. This procedure relies upon the use of a new PCP OpCode and Option: GET/NEXT. | ||||||||||||||||
| draft-boucadair-pcp-rtp-rtcp-04.txt | |||||||||||||||||
| Reserving N and N+1 Ports with PCP | |||||||||||||||||
|
This document defines a new PCP Option to reserve a pair of ports (N and N+1) by a PCP-controlled device while preserving the parity and contiguity. This PCP Option eases the NAT traversal for applications having requirements on the port parity and contiguity (e.g., RTP/ RTCP). | ||||||||||||||||
| draft-boutros-l2vpn-mpls-tp-mac-wd-00.txt | |||||||||||||||||
| MAC Address Withdrawal over Static Pseudowire | |||||||||||||||||
|
This document specifies a mechanism to signal MAC address withdrawal notification using PW Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in VPLS/H-VPLS environment. This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union Telecommunication 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. | ||||||||||||||||
| draft-brandenburg-cdni-has-01.txt | |||||||||||||||||
| Models for adaptive-streaming-aware CDN Interconnection | |||||||||||||||||
|
This documents presents thoughts on the potential impact of supporting HTTP Adaptive Streaming technologies in CDN Interconnection scenarios. Our intent is to spur discussion on how the different CDNI interfaces could, and should, deal with content delivered using adaptive streaming technologies and to facilitate working group decisions. | ||||||||||||||||
| draft-briscoe-conex-initial-deploy-02.txt | |||||||||||||||||
| Initial Congestion Exposure (ConEx) Deployment Examples | |||||||||||||||||
|
This document gives examples of how ConEx deployment might get started, focusing on unilateral deployment by a single network. | ||||||||||||||||
| draft-briscoe-conex-re-ecn-motiv-00.txt | |||||||||||||||||
| Re-ECN: A Framework for adding Congestion Accountability to TCP/IP | |||||||||||||||||
|
This document describes a framework for using a new protocol called re-ECN (re-inserted explicit congestion notification), which can be deployed incrementally around unmodified routers. Re-ECN allows accurate congestion monitoring throughout the network thus enabling the upstream party at any trust boundary in the internetwork to be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability for congestion and policing mechanisms for incoming traffic from end- customers or from neighbouring network domains. As well as giving the motivation for re-ECN this document also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end- points will be to use the protocol honestly. Note concerning Intended Status: If this draft were ever published as an RFC it would probably have historic status. There is limited space in the IP header, so re-ECN had to compromise by requiring the receiver to be ECN-enabled otherwise the sender could not use re-ECN. Re-ECN was a precursor to chartering of the IETF's Congestion Exposure (ConEx) working group, but during chartering there were still too few ECN receivers enabled, therefore it was decided to pursue other compromises in order to fit a similar capability into the IP header. | ||||||||||||||||
| draft-briscoe-conex-re-ecn-tcp-00.txt | |||||||||||||||||
| Re-ECN: Adding Accountability for Causing Congestion to TCP/IP | |||||||||||||||||
|
This document introduces re-ECN (re-inserted explicit congestion notification), which is intended to make a simple but far-reaching change to the Internet architecture. The sender uses the IP header to reveal the congestion that it expects on the end-to-end path. The protocol works by arranging an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. It can be deployed incrementally around unmodified routers. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It briefly gives examples of mechanisms that can use the protocol to ensure data sources respond sufficiently to congestion, but these are described more fully in a companion document. Note concerning Intended Status: If this draft were ever published as an RFC it would probably have historic status. There is limited space in the IP header, so re-ECN had to compromise by requiring the receiver to be ECN-enabled otherwise the sender could not use re-ECN. Re-ECN was a precursor to chartering of the IETF's Congestion Exposure (ConEx) working group, but during chartering there were still too few ECN receivers enabled, therefore it was decided to pursue other compromises in order to fit a similar capability into the IP header. | ||||||||||||||||
| draft-briscoe-intarea-ipv4-id-reuse-01.txt | |||||||||||||||||
| Reusing the IPv4 Identification Field in Atomic Packets | |||||||||||||||||
|
This specification takes a new approach to extensibility that is both principled and a hack. It builds on recent moves to formalise the increasingly common practice where fragmentation in IPv4 more closely matches that of IPv6. The large majority of IPv4 packets are now 'atomic', meaning indivisible. In such packets, the 16 bits of the IPv4 Identification (IPv4 ID) field are redundant and could be freed up for the Internet community to put to other uses, at least within the constraints imposed by their original use for reassembly. This specification defines the process for redefining the semantics of these bits. It uses the previously reserved control flag in the IPv4 header to indicate that these 16 bits have new semantics. Great care is taken throughout to ease incremental deployment, even in the presence of middleboxes that incorrectly discard or normalise packets that have the reserved control flag set. | ||||||||||||||||
| draft-bryan-ftp-range-06.txt | |||||||||||||||||
| File Transfer Protocol RANG Command for Octet Ranges | |||||||||||||||||
|
The File Transfer Protocol offers the REST command to designate a starting point for a transfer, but does not currently offer any method to specify an end point. This document specifies a new FTP RANG command to be used by clients to designate a start and end point to permit restarts and repairs of interrupted data transfers in STREAM mode. | ||||||||||||||||
| draft-bryan-ftpext-hash-00.txt | |||||||||||||||||
| File Transfer Protocol HASH Command for Cryptographic Hashes | |||||||||||||||||
|
The File Transfer Protocol does not offer any method to verify the integrity of a transferred file, nor can two files be compared against each other without actually transferring them first. Cryptographic hashes are a possible solution to this problem. In the past, several attempts have been made to add commands to obtain checksums and hashes, however none have been formally specified, leading to non-interoperability and confusion. To solve these issues, this document specifies a new FTP command to be used by clients to request cryptographic hashes of files. | ||||||||||||||||
| draft-bryant-ipfrr-tunnels-03.txt | |||||||||||||||||
| IP Fast Reroute using tunnels | |||||||||||||||||
|
This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. This IP Fast Reroute advanced method was invented in 2002 and draft (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It was one of the first methods of achieving full repair coverage in an IP Network, and as such the draft has been widely referenced in the academic literature. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been invented. | ||||||||||||||||
| draft-bundesbank-eurosystem-namespace-00.txt | |||||||||||||||||
| A Uniform Resource Name (URN) Namespace for Eurosystem Messaging | |||||||||||||||||
|
This document describes a Uniform Resource Name (URN) namespace that is ma- naged by Deutsche Bundesbank (member of ESCB) for usage within messages standardized by the Eurosystem. | ||||||||||||||||
| draft-burnett-rtcweb-constraints-registry-01.txt | |||||||||||||||||
| IANA Registry for RTCWeb Media Constraints | |||||||||||||||||
|
Specifications in W3C's Media Capture Task Force and WebRTC Working Group have need of a registry in which to maintain a list of HTML Media constraints. This document defines this registry. | ||||||||||||||||
| draft-bvandervalk-sadi-00.txt | |||||||||||||||||
| SADI: Semantic Automated Discovery and Integration | |||||||||||||||||
|
This document describes Semantic Automated Discovery and Integration (SADI), a set of best practices for implementing stateless web services that consume RDF data as input and generate RDF data as output. The goal of SADI is to establish conventions that will enable a much higher level of interoperability between web services from independent providers than is currently possible under the widespread use of WSDL/XML and RESTful services. Under SADI, interoperability depends on the shared use of predicate vocabularies, rather than the shared use of particular XML schemas, JSON structures, or ad hoc data formats. Through the use of OWL to describe service input and output datatypes, SADI enables: i) automated discovery of services that provide data or computations of interest, and ii) automated matchmaking between local data and available services. By iterative application of the former two capabilities, SADI enables semi-automated construction of arbitrarily complex workflows across independent service providers. | ||||||||||||||||
| draft-cai-softwire-6rd-mib-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-cailleux-secure-headers-01.txt | |||||||||||||||||
| Securing Header Fields with S/MIME | |||||||||||||||||
|
This document describes how the S/MIME protocol can be extended in order to secure message header fields. This technology provides security services such as data integrity, non-repudiation and confidentiality. This extension is referred to as 'Secure Headers'. | ||||||||||||||||
| draft-cakulev-emu-eap-ibake-02.txt | |||||||||||||||||
| An EAP Authentication Method Based on Identity-Based Authenticated Key Exchange | |||||||||||||||||
|
The Extensible Authentication Protocol (EAP) is an authentication framework which supports multiple authentication methods. This document defines an authentication method for EAP called EAP-IBAKE, which is based on the Identity-Based Authenticated Key Exchange (IBAKE) protocol. The IBAKE method provides mutual authentication through the use of identity-based encryption. In addition to mutual authentication this method also provides perfect forward and backwards secrecy. | ||||||||||||||||
| draft-cal-resource-vcard-00.txt | |||||||||||||||||
| vCard representation of resources for calendaring and scheduling services | |||||||||||||||||
|
This specification describes the vCard representation of resources for calendaring and scheduling. A resource in the scheduling context is any shared entity that can be scheduled by a calendar user, but does not control its own attendance status. | ||||||||||||||||
| draft-caldwell-tbsa-00.txt | |||||||||||||||||
| Trusted Browser Security Architecture (TBSA) | |||||||||||||||||
|
This document proposes a trusted browser security model intended to secure the mutual automated consent between the end-user and the content provider before allowing a web browser to engage the services of an arbitrary third-party add-on, extension or service. Properly implemented, this proposed security model would create a standardized API across all browsers to further the security of e-commerce and other on-line transactions. | ||||||||||||||||
| draft-campagna-suitee-03.txt | |||||||||||||||||
| A Cryptographic Suite for Embedded Systems (SuiteE) | |||||||||||||||||
|
This document describes a cryptographic suite of algorithms ideal for constrained embedded systems. It uses the existing IEEE 802.15.4 standard as a starting point, builds upon existing embedded cryptographic primitives and suggests additional elliptic curve cryptography (ECC) algorithms and curves. The goal is to define a complete suite of algorithms ideal for embedded systems. | ||||||||||||||||
| draft-cao-core-pd-01.txt | |||||||||||||||||
| HTTP-COAP Proxy Discovery using Link-format | |||||||||||||||||
|
This document discusses the problem of HTTP-COAP proxy discovery and proposes a method of using Link-format to do the job. | ||||||||||||||||
| draft-cao-l2vpn-vpls-etree-02.txt | |||||||||||||||||
| Extension to VPLS for E-Tree | |||||||||||||||||
|
This document proposes an approach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtual Private LAN Service [RFC4761] [RFC4762]. The proposed solution is characterized by breaking pseudowire setup between Leaf endpoints in E-Tree instance to fulfill the specific E-Tree requirement: Leaf cannot communicate with Leaf. Backward compatibility is also considered in this document. | ||||||||||||||||
| draft-cao-lwig-dns-serv-simp-00.txt | |||||||||||||||||
| Lightweight Service Simplification via DNS | |||||||||||||||||
|
This memo discusses a lightweight service simplification method via DNS. Instead of storing the information on the Web infrastructure, the service provider can store them on the DNS servers. By expressing these information in the DNS Resource Records, the requester can get these information directly during the DNS name resolution, without the need of accessing any web resource. This way eliminates the overhead caused by TCP handshake and HTTP get/ response, and can be served as a lightweight information provisioning method. | ||||||||||||||||
| draft-cao-open-sec-00.txt | |||||||||||||||||
| The Architecture of Open Security Capability | |||||||||||||||||
|
This position paper introduces an architecture of opening the operator's security capability to third party smart object applications. With this architecture, the authentication, integrity and encryption capabilities can be wrapped up as Application Programming Interfaces and provided to third party application developers. So the third party applications do not have to spare energy on these basic security functionalities. As a consequence, the barrier for new applications is lowered, and it avoids the need of providing security by multiple applications and hence saves the computing and communication resources on constrained nodes. Note: This document is submitted for the IAB Workshop on Smart Object Security on March 23, 2012, Paris. | ||||||||||||||||
| draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-05.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-capelastegui-mmusic-3dv-sdp-00.txt | |||||||||||||||||
| 3D Video in the Session Description Protocol (SDP) | |||||||||||||||||
|
This document defines a mechanism to describe 3D video streams in the Session Description Protocol (SDP). This includes 3D video streams composed of multiple video views, or of a combination of views and depth maps. Several 3D video formats are supported, including simulcast, video-plus-depth, and frame-packing. A new decoding dependency, "3dd", is defined, describing the association between media stream belonging to a 3D video stream. In addition, a new SDP media-level attribute, "3dvFormat", is defined, describing the format used by media streams within a 3D video stream. | ||||||||||||||||
| draft-cardenas-dff-05.txt | |||||||||||||||||
| Depth-First Forwarding in Unreliable Networks | |||||||||||||||||
|
This document describes the Depth-First Forwarding (DFF) protocol for IPv6 networks based on the LoWPAN adaptation layer as specified in RFC4944. The protocol is a mesh-under data forwarding mechanism that increases reliability of data delivery. DFF forwards data frames using a network-wide "depth-first search" for the Final Destination of the frame. DFF may be used in conjunction with a routing protocol, which provides "hints" for DFF in which order to try to send the frame to the neighbors discovered by the neighborhood discovery mechanism. In that case, DFF can be used as local repair mechanism. | ||||||||||||||||
| draft-carlberg-tsvwg-ecn-reactions-01.txt | |||||||||||||||||
| Reactions to Signaling from ECN Support for RTP/RTCP | |||||||||||||||||
|
This document presents recommendations for response to Congestion Experience (CE) notifications by real time applications that have negotiated end-to-end support of Explicit Congestion Notification (ECN). This document is a follow-on effort of [draft-rtp-ecn], which specifies the signaling used to provide ECN support for RTP/RTCP flows. | ||||||||||||||||
| draft-carpenter-6man-uri-zoneid-01.txt | |||||||||||||||||
| Representing IPv6 Zone Identifiers in Uniform Resource Identifiers | |||||||||||||||||
|
This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a Uniform Resource Identifier that includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. | ||||||||||||||||
| draft-carpenter-6renum-static-problem-02.txt | |||||||||||||||||
| Problem Statement for Renumbering IPv6 Hosts with Static Addresses | |||||||||||||||||
|
This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that for operational reasons require static addresses. | ||||||||||||||||
| draft-carpenter-flow-label-balancing-00.txt | |||||||||||||||||
| Using the IPv6 Flow Label for Server Load Balancing | |||||||||||||||||
|
This document describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. | ||||||||||||||||
| draft-carpenter-v6ops-icp-guidance-03.txt | |||||||||||||||||
| IPv6 Guidance for Internet Content and Application Service Providers | |||||||||||||||||
|
This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to any enterprise network preparing for IPv6 users. | ||||||||||||||||
| draft-carpenter-v6ops-label-balance-02.txt | |||||||||||||||||
| Using the IPv6 Flow Label for Server Load Balancing | |||||||||||||||||
|
This document describes how the IPv6 flow label can be used in support of layer 3/4 load distribution and balancing for large server farms. | ||||||||||||||||
| draft-carrozzo-pce-pcep-route-price-00.txt | |||||||||||||||||
| PCEP extensions for the computation of route offers with price | |||||||||||||||||
|
The PCE defined in RFC4655 is a functional entity generally confined in the control plane to elaborate explicit optimal routes with related costs to be installed as [G]MPLS tunnels/LSPs. The resulting route cost(s)/metric(s) are Traffic Engineering indicators used by the network administrator (carrier) to optimize the usage of its network resources. In this document a framework for the usage of PCE in cooperation with the Network Service and Business Plane (NSBP) is proposed, along with related PCEP extensions. The NSBP invokes this extended PCE (service PCE) to trigger the computation of network service offers with related price information. The price of a network connectivity service generally depends on strategic factors, but it could also be influenced by the amount of mobilized network resources (along the route), the ingress/egress interfaces/PoPs, etc. Therefore, it could be provided by an extended service-PCE as an additional route information. This document focuses on the extensions to the PCEP protocol in support of the computation of route prices for intra- and inter- domain network connectivity services. Mechanisms for elaborating and retrieving price information in the PCE are vendor-specific and out of the scope of this document. | ||||||||||||||||
| draft-castellani-core-alive-00.txt | |||||||||||||||||
| CoAP Alive Message | |||||||||||||||||
|
In the context of a Constrained RESTful Environment (CoRE), hosts could frequently be energy-constrained and be turned off the vast majority of time for energy-saving purposes. In the case of a CoAP server, while it is offline, it is neither available to serve requests. Clients desiring to access its resources have no way to understand when they will find it up again. This specification provides a simple new message that gives to a CoAP server the ability to signal its current availability in the network. | ||||||||||||||||
| draft-castellani-core-http-mapping-04.txt | |||||||||||||||||
| Best practices for HTTP-CoAP mapping implementation | |||||||||||||||||
|
This draft aims at being a base reference documentation for HTTP-CoAP proxy implementors. It details deployment options, discusses possible approaches for URI mapping, and provides useful considerations related to protocol translation. | ||||||||||||||||
| draft-castellani-lwig-coap-separate-responses-00.txt | |||||||||||||||||
| Learning CoAP separate responses by examples | |||||||||||||||||
|
This draft aims at providing interesting examples of CoAP separate responses that are useful to aid CoAP implementers on understanding possible rare situation incurring. | ||||||||||||||||
| draft-cavuto-dtcp-03.txt | |||||||||||||||||
| DTCP: Dynamic Tasking Control Protocol | |||||||||||||||||
|
Dynamic Tasking Control Protocol is a message-based interface by which an authorized client may connect to a server -- usually a network element (NE) or security policy enforcement point (PEP) -- and issue dynamic requests for data. These tasking requests contain, among other parameters, packet matching criteria that may apply to certain packets flowing through that network element. The primary intent of the tasking request is to instruct that network element to send copies of packets matching those criteria to a destination (usually via tunneling) for further inspection or other action. The protocol contains a security architecture to address client or server spoofing as well as replay prevention. The protocol assumes that multiple clients may simultaneously control a single server. | ||||||||||||||||
| draft-cazeaux-clue-sip-signaling-01.txt | |||||||||||||||||
| Requirements for ControLling mUltiple streams for tElepresence (CLUE) signaling. | |||||||||||||||||
|
This document defines requirements relating to the design of CLUE signaling. This document also proposes two alternative design approaches to CLUE signaling. | ||||||||||||||||
| draft-cbcs-ccamp-sson-guard-bands-reqs-00.txt | |||||||||||||||||
| Guard Bands requirements for GMPLS controlled optical networks | |||||||||||||||||
|
The continuous increase of flexibility and bit rate in optical networks has higher and higher impacts on inter-channel effects (e.g. Cross-phase modulations). This effect leads to the introduction of Guard Bands between adjacent light paths in order to reduce the inter-channel detrimental effects. This document provides requirements for the devolpment of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) management of Guard Bands. | ||||||||||||||||
| draft-cbran-rtcweb-codec-02.txt | |||||||||||||||||
| WebRTC Codec and Media Processing Requirements | |||||||||||||||||
|
This document outlines the codec and media processing requirements for WebRTC client application and endpoint devices. | ||||||||||||||||
| draft-chakrabarti-nordmark-energy-aware-nd-02.txt | |||||||||||||||||
| Energy Aware IPv6 Neighbor Discovery Optimizations | |||||||||||||||||
|
IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for neighbor's address resolution, unreachability detection, address autoconfiguration, router advertisement and solicitation. With the progress of Internet adoption on various industries including home, wireless and machine-to-machine communications, there is a desire for optimizing legacy IPv6 Neighbor Discovery protocol to be more efficient in terms of number of signaling messages in the network. Efficient IPv6 Neighbor Discovery is useful for energy-efficient networks and as well for overlay networks such as VLANs with large number of nodes. This document describes a method of optimizations by reducing periodic multicast messages, frequent Neighbor Solicitation messages and discusses interoperability with legacy IPv6 nodes. It also addresses the ND denial of service issues by introducing node Registration procedure. | ||||||||||||||||
| draft-chan-dmm-architecture-00.txt | |||||||||||||||||
| A architecture of distributed mobility management using mip and pmip | |||||||||||||||||
|
This draft proposes a distributed architecture of mobility management in terms of abstracted logical functions. Mobility management functions are abstracted into different logical functions: (1) allocation of home network prefixes or home addresses to mobile nodes; (2) location management which includes managing the IP addresses and locations of the mobile nodes; and (3) mobility routing which includes intercepting and forwarding packets. A distributed architecture can be contructed by providing the mobility routing functions in multiple networks in the data plane and a distributed database is used to host the location management function. This generalized architecture enables different distributed mobility designs using primarily the existing mobility protocols (MIP and PMIP) and their extensions. Several existing distributed mobility management proposals are briefly reviewed using this framework. It is expected that the different proposals, when expressed in terms of the generalized framework of logical functions, can interwork with each other as well as with the existing hierarchical deployments. | ||||||||||||||||
| draft-chan-dmm-requirements-00.txt | |||||||||||||||||
| Requirements of distributed mobility management | |||||||||||||||||
|
The traditional hierarchical structure of cellular networks has led to deployment models which are heavily centralized. Mobility management with centralized mobility anchoring in existing hierarchical mobile networks is quite prone to suboptimal routing and issues related to scalability. Centralized functions present a single point of failure, and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. To make matters worse, there are numerous variants of Mobile IP in addition to other protocols standardized outside the IETF, making it much more difficult to create economical and interoperable solutions. In this document we examine the problems of centralized mobility management and identify requirements for distributed and dynamic mobility management. | ||||||||||||||||
| draft-chandra-hegde-mpoint-bfd-for-mpls-00.txt | |||||||||||||||||
| Multipoint BFD for MPLS | |||||||||||||||||
|
Recent proposals have extended the use of Bidirectional Forwarding Detection to detect data plane failures in multipoint networks. One desirable application of Multipoint BFD [MP-BFD] is to detect data path failures in point-to-multipoint Label Switched Paths (P2MP LSPs). The scope of this document is to discuss the applicability of multipoint BFD for fault detection in the data plane of P2MP LSPs. The document extends the techniques and mechanisms mentioned in [RFC5884] and applies them to MPLS P2MP environment. | ||||||||||||||||
| draft-chen-bgp-ext-community-orf-02.txt | |||||||||||||||||
| Extended Community Based Outbound Route Filter for BGP-4 | |||||||||||||||||
|
This document defines two new Outbound Router Filter types for BGP, termed "Extended Community Outbound Route Filter Type I", and "Extended Community Outbound Route Filter Type II", that can be used to perform extended community based route filtering. | ||||||||||||||||
| draft-chen-l2vpn-vpls-etree-vlan-01.txt | |||||||||||||||||
| Automatic VLAN allocation in E-tree | |||||||||||||||||
|
This document proposes to use automatically allocated VLAN ID to indicate E-Tree attribute. For the E-Tree requirement, please refer to [I-D.ietf-l2vpn-etree-reqt] for detail. | ||||||||||||||||
| draft-chen-mif-happy-eyeballs-extension-04.txt | |||||||||||||||||
| Happy Eyeballs Extension for Multiple Interfaces | |||||||||||||||||
|
The memo has been proposed to extend happy eyeballs algorithm to fit into multiple interfaces environment. Based on this extended heuristic algorithm, a client with multiple interface could determine the optimal flow path in which specific interface has been chosen. Furthermore, an appropriate IP address family for each interface can be also identified to guarantee user experiences during IPv6 transition period. | ||||||||||||||||
| draft-chen-mpls-ipv6-pw-lsp-ping-03.txt | |||||||||||||||||
| Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs | |||||||||||||||||
|
Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and Traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and Traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. | ||||||||||||||||
| draft-chen-mpls-p2mp-egress-protection-05.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-chen-mpls-p2mp-ingress-protection-05.txt | |||||||||||||||||
| Extensions to RSVP-TE for P2MP LSP Ingress Local Protection | |||||||||||||||||
|
This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node 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. | ||||||||||||||||
| draft-chen-ospf-ttz-01.txt | |||||||||||||||||
| OSPF Topology-Transparent Zone | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-chen-pce-compute-backup-egress-04.txt | |||||||||||||||||
| Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path | |||||||||||||||||
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress. | ||||||||||||||||
| draft-chen-pce-compute-backup-ingress-04.txt | |||||||||||||||||
| Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path | |||||||||||||||||
|
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress. | ||||||||||||||||
| draft-chen-pce-forward-search-p2mp-path-03.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-chen-pce-forward-search-p2p-path-computation-03.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-chen-pce-protection-applicability-00.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-chen-pcp-mobile-deployment-00.txt | |||||||||||||||||
| Cases Study- PCP Deployment in Mobile Network | |||||||||||||||||
|
This memo provided two cases study, when PCP is deployed in mobile network. Some motivation of deployment PCP in mobile network was described and justification for each deployment case was stated. Corresponding to each mode, the document discussed some features to address operational issues. That might potentially cause some extension on PCP protocol level. | ||||||||||||||||
| draft-chen-softwire-4rd-u-comment-00.txt | |||||||||||||||||
| A Commentary on 4rd-U Architecture and Semantics | |||||||||||||||||
|
4rd-U is proposed as an effort of unifying encapsulation and double translation solutions for the softwire of IPv4 over IPv6 domain. This attempt introduces new behaviors in the Internet transition architecture as well as semantics other than that of well-known Internet protocols. This documents provides a commentary on the semantic changes and their impacts. | ||||||||||||||||
| draft-chen-v6ops-nat64-experience-01.txt | |||||||||||||||||
| NAT64 Operational Experiences | |||||||||||||||||
|
This document summarizes some stateful NAT64 deployment scenarios and operational experiences for NAT64-CGN and NAT64-CE. | ||||||||||||||||
| draft-cheng-behave-cgn-cfg-radius-ext-03.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-cheung-mpls-tp-mesh-protection-05.txt | |||||||||||||||||
| MPLS-TP Shared Mesh Protection | |||||||||||||||||
|
This document describes a mechanism to address the requirement to support protection of Label Switched Paths (LSPs) in an MPLS Transport Profile (MPLS-TP) mesh topology. The shared mesh protection mechanism enables multiple protection paths within a shared mesh protection domain to share protection resources for the protection of working paths by coordinating protection switching operations according to the priority assigned to each end-to-end linear protection domain. 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. | ||||||||||||||||
| draft-chkpvc-enterprise-incremental-ipv6-00.txt | |||||||||||||||||
| Enterprise Incremental IPv6 | |||||||||||||||||
|
Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and potentially an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. | ||||||||||||||||
| draft-chown-mboned-multicast-filtering-02.txt | |||||||||||||||||
| Multicast Filtering Practices | |||||||||||||||||
|
Operators of multicast networks may apply various filters to multicast traffic at boundary routers or on MSDP peerings. The aim of this text is to discuss appropriate filtering policies, as well as documenting existing filtering practices, with a view to generating some discussion towards producing guidance on best filtering practice. | ||||||||||||||||
| draft-chunduri-isis-extended-sequence-no-tlv-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-chunduri-karp-is-is-gap-analysis-01.txt | |||||||||||||||||
| KARP IS-IS security gap analysis | |||||||||||||||||
|
This document analyzes the threats applicable for Intermediate system to Intermediate system (IS-IS) routing protocol and security gaps according to the KARP Design Guide. This document also provides specific requirements to address the gaps with both manual and auto key management protocols. | ||||||||||||||||
| draft-chunduri-karp-using-ikev2-with-tcp-ao-01.txt | |||||||||||||||||
| Using IKEv2 with TCP-AO | |||||||||||||||||
|
This document describes a mechanism to secure TCP-based pairwise Routing Protocol (RP) associations using the IKEv2 Key Management Protocol (KMP) integrated with TCP-AO. A Gatekeeper (GK) mechanism is introduced to allow TCP-AO to coordinate with IKEv2 without fundamental modification to either. This document also introduces extensions to IKEv2 and its Security Associations to enable its key negotiation to support TCP-AO. The document also includes a summary of IKEv2 authentication methods available for peer authentication for use in protecting routing protocols. | ||||||||||||||||
| draft-clausen-lln-loadng-04.txt | |||||||||||||||||
| The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) | |||||||||||||||||
|
This document describes the LLN Ad hoc On-Demand - Next Generation (LOADng) distance vector routing protocol, a reactive routing protocol intended for use in Low power and Lossy Networks (LLN). The protocol is derived from AODV (RFC3561) and extended for use in LLNs. | ||||||||||||||||
| draft-clausen-lln-rpl-experiences-03.txt | |||||||||||||||||
| Experiences with RPL: IPv6 Routing Protocol for Low power and Lossy Networks | |||||||||||||||||
|
With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" - having been published as a Proposed Standard after a ~2-year development cycle, this document presents an evaluation of the resulting protocol, of its applicability, and of its limits. The documents presents a selection of observations of the protocol characteristics, exposes experiences acquired when producing various prototype implementations of RPL, and presents results obtained from testing this protocol - by way of network simulations, in network testbeds and in deployments. The document aims at providing a better understanding of possible weaknesses and limits of RPL, notably the possible directions that further protocol developments should explore, in order to address these. | ||||||||||||||||
| draft-coene-rserpool-applic-ipfix-13.txt | |||||||||||||||||
| Reliable Server Pooling Applicability for IP Flow Information Exchange | |||||||||||||||||
|
This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. | ||||||||||||||||
| draft-cohn-mpls-tp-pw-protection-02.txt | |||||||||||||||||
| MPLS-TP Linear Protection Applicability to MS-PW | |||||||||||||||||
|
One of the requirements of the MPLS transport profile [RFC5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs as defined in [RFC6073]. | ||||||||||||||||
| draft-contreras-multimob-rams-04.txt | |||||||||||||||||
| PMIPv6 multicast handover optimization by the Request of Active Multicast Subscription (RAMS) | |||||||||||||||||
|
This document specifies a multicast handover optimization mechanism for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism is based on speeding up the acquisition of mobile nodes' active multicast subscriptions information by the mobile access gateways. To do that, extensions to the current Proxy Mobile IPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but also can be applied to other solutions envisioned as possible architectural evolutions of it. Furthermore, they are also independent of the role played by the mobile access gateway within the multicast network (either acting as multicast listener discovery proxy or multicast router). | ||||||||||||||||
| draft-cordell-lumas-05.txt | |||||||||||||||||
| Lumas - Language for Universal Message Abstraction and Specification | |||||||||||||||||
|
A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire. | ||||||||||||||||
| draft-cui-mpls-tp-cc-cv-rdi-id-00.txt | |||||||||||||||||
| Using ITU-T-based IDs for MPLS-TP Proactive Connectivity Verification | |||||||||||||||||
|
This document defines how to use ICC-based Multiprotocol Label Switching Transport Profil(MPLS-TP) identifiers for proactive connectivity verification (CV) analogous to RFC 6428. New TLVs are defined to support proactive CV based on identifiers following ITU-T conventions. | ||||||||||||||||
| draft-cui-mpls-tp-on-demand-cv-id-00.txt | |||||||||||||||||
| Using ITU-T-based IDs for MPLS-TP On-demand Connectivity Verification | |||||||||||||||||
|
This document defines how to use ICC-based MPLS-TP identifiers for on-demand connectivity verification (CV) analogous to RFC 6426. New TLVs are defined to support on-demand CV based on identifiers following ITU-T conventions. | ||||||||||||||||
| draft-cui-softwire-b4-translated-ds-lite-06.txt | |||||||||||||||||
| Lightweight 4over6: An Extension to the DS-Lite Architecture | |||||||||||||||||
|
This document specifies an extension to DS-Lite called Lightweight 4over6. This mechanism moves the translation function from the tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the mapping scale on the concentrator to a per-subscriber level. To delegate the NAPT function to the initiators, port-restricted IPv4 addresses are allocated to the initiators. | ||||||||||||||||
| draft-cui-softwire-mesh-mib-04.txt | |||||||||||||||||
| Softwire Mesh 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 defines objects for managing softwire mesh [RFC5565]. | ||||||||||||||||
| draft-cui-tictoc-encrypted-synchronization-00.txt | |||||||||||||||||
| Practical solutions for encrypted synchronization protocol | |||||||||||||||||
|
This informational document analyzes the accuracy issues with time synchronization protocols when time synchronization packets are encrypted during transmission. In addition, several candidate solutions on such issues are introduced. | ||||||||||||||||
| draft-daboo-caldav-attachments-01.txt | |||||||||||||||||
| CalDAV Managed Attachments | |||||||||||||||||
|
This document defines how CalDAV servers can provide server managed collections to allow attachments associated with iCalendar data, to be stored and managed on the server. | ||||||||||||||||
| draft-daboo-vcard4-ldap-mapping-00.txt | |||||||||||||||||
| Mapping of VCard 4 Properties to LDAP objectclasses and attributes | |||||||||||||||||
|
This specification describes a mapping of standard VCard 4 properties to standard LDAP objectclasses and attributes. | ||||||||||||||||
| draft-dalela-dc-approaches-00.txt | |||||||||||||||||
| Datacenter Solution Approaches | |||||||||||||||||
|
There are many approaches to addressing virtualized datacenter scaling problems. Examples of these approaches include, L2 vs. L3 forwarding, host-based vs. network-based solutions, fat-access and lean-core vs. fat-core and lean-access, flat addressing vs. encapsulation, protocol learning vs. directories for location discovery, APIs vs. protocols for orchestration, etc. Different solutions being proposed today take one or more of these approaches in combination, although sometimes the question of approach itself may not be settled. Given the multiple facets of the datacenter problem, and many approaches to solve each problem, it becomes hard to discuss a solution when some approaches may be acceptable while others are not. This document discusses the pros and cons of various approaches. The goal is not to describe a specific solution, but to evaluate the various approaches. This document concludes with a set of recommendations on which approaches are most optimal for a holistic solution to the entire problem set. | ||||||||||||||||
| draft-dalela-dc-requirements-00.txt | |||||||||||||||||
| Datacenter Network and Operations Requirements | |||||||||||||||||
|
The problems of modern datacenters are rooted in virtualized host scaling. Virtualization implies VM mobility, which may be intra- datacenter or inter-datacenter. Mobility may cross administrative boundaries, such as across private-public domains. A public datacenter may be multi-tenant, extending several private networks into the public domain. Running these massively scaled, virtualized, multi-tenant datacenters poses some unique networking and operational challenges. This document describes these challenges. | ||||||||||||||||
| draft-dalela-orchestration-00.txt | |||||||||||||||||
| Service Orchestration Protocol (SOP) Requirements | |||||||||||||||||
|
Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for a standard protocol for exchanging service information. This draft describes requirements for such a protocol. Current cloud implementations expose application level APIs, which are not syntactically and semantically compatible with each other. One approach to interoperate cloud services is to standardize the protocol while leaving the API definition implementation specific. Standard protocols have been used widely in the Internet and can be extended to cloud. Use of such protocols is compatible with existing cloud APIs, which can exchange information in a standard protocol. New APIs may also be developed using a standard protocol. By this, it would be possible to interoperate diverse APIs across service providers, service vendors and service users. | ||||||||||||||||
| draft-dalela-sdf-00.txt | |||||||||||||||||
| Service Description Framework (SDF) | |||||||||||||||||
|
Cloud services need to interoperate across providers, vendors and private/public domains. To enable this interoperability, there should be a standard way to exchange service information. The purpose of this document is to detail different kinds of information necessary to describe services. We identify the following kinds of service- dependant information needed for any kind of service: - Method for naming services and identifying service classes. - Method for describing syntax for properties of service classes. - Method for defining semantics in a service class, by establishing | ||||||||||||||||
| draft-dalela-sop-00.txt | |||||||||||||||||
| Service Orchestration Protocol | |||||||||||||||||
|
Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for a standard wire-format for exchanging service information. This document describes a Service Orchestration Protocol (SOP) to be used as a standard wire-format for cloud exchanges. Similar to widely used protocols like HTTP, SIP and SMTP, SOP uses text-based messages, which are easily extensible and may be inspected at cloud proxies. While SOP carries service-independent information, service-dependant information is attached as a Service Description Framework [SDF] payload to SOP packets. This is similar to how HTML is transported over HTTP. SDF is a XML schema for describing services. SOP and SDF enable any kind of service to be discovered and orchestrated across private and public domains. Simple protocol compliance tests can be employed to ensure interoperability across domains. SOP wire-formats can be used with existing cloud APIs. Using these, it would be possible to interoperate diverse APIs and cloud services across service providers, service vendors and service users. | ||||||||||||||||
| draft-dalela-sop-architecture-00.txt | |||||||||||||||||
| SOP Network Architecture | |||||||||||||||||
|
Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for network level deployment architecture to connect users and providers. This document describes functionality partitioning in network deployment and the different advantages of using distributed functionality deployments. | ||||||||||||||||
| draft-dalela-sop-flows-00.txt | |||||||||||||||||
| SOP Message Flows | |||||||||||||||||
|
This document describes the Service Orchestration Protocol (SOP) message flows for some important service orchestration scenarios. The flows contain complete packet information including both SOP and Service Description Framework (SDF) payloads. The message flows in this document are by no means exhaustive, but they carry sufficient information using which other flows can be easily constructed. The deployment scenarios for services are varied, and it is not possible to cover every possible scenario. Nevertheless, those flows will follow closely the information given in this document. | ||||||||||||||||
| draft-das-paws-protocol-01.txt | |||||||||||||||||
| Device to Database Protocol for White Space | |||||||||||||||||
|
This document describes the `White Space Device` to `Database` interface protocol features and functionalities and shows in Appendix A how they are consistent with the protocol requirements specified in [I-D.ietf-paws-problem-stmt-usecases-rqmts]. | ||||||||||||||||
| draft-davie-stt-01.txt | |||||||||||||||||
| A Stateless Transport Tunneling Protocol for Network Virtualization (STT) | |||||||||||||||||
|
Network Virtualization places unique requirements on tunneling protocols. This draft describes STT (Stateless Transport Tunneling), a tunnel encapsulation that enables overlay networks to be built in virtualized networks. STT is particularly useful when some tunnel endpoints are in end-systems, as it utilizes the capabilities of the network interface card to improve performance. | ||||||||||||||||
| draft-davies-idntables-01.txt | |||||||||||||||||
| Representing registration policy for IDNs using XML | |||||||||||||||||
|
This memo describes a method of representing the registration policy that a zone administrator uses for registering Internationalised Domain Names using Extensible Markup Language (XML). These registry policies, commonly known as "IDN tables", are used to enforce and share policy on which specific code-points are permitted for registrations, and which alternative code-points are considered variants. | ||||||||||||||||
| draft-dawes-dispatch-debug-00.txt | |||||||||||||||||
| Session Initiation Protocol (SIP) Header Parameter for Debugging | |||||||||||||||||
|
Networks that use SIP to start and stop sessions between their users will frequently be upgraded with software and hardware changes. Users will similarly frequently change their client software and the way they use the network. In order to allow troubleshooting and regression testing, it is useful to provide debugging as part of the network fabric. This draft describes an event package that provides debugging configuration to SIP entities and a SIP private header that triggers logging of SIP signalling and identifies logs at mulitiple SIP entities as belonging to a single end-to-end session. A list of related IETF drafts and non-IETF specifications is included to help develop this topic. | ||||||||||||||||
| draft-dawes-dispatch-mediasec-parameter-05.txt | |||||||||||||||||
| Capability Exchange for Media Plane Security | |||||||||||||||||
|
Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is already described in an RFC. This document extends negotiation of a security mechanism to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label security mechanisms that apply to the media plane. | ||||||||||||||||
| draft-deason-afs3-oob-00.txt | |||||||||||||||||
| Data Transmission Over Out-of-Band Alternative Tranports for AFS-3 | |||||||||||||||||
|
This document describes an extension to AFS-3 which allows data transfer over arbitrary alternative transports to the traditional Rx RPC over UDP, and describes a method of using TCP as one such alternative transport. This document describes new wire structures and Rx RPCs for the 'afsint' protocol in AFS-3. Internet Draft Comments Comments regarding this draft are solicited. Please include the AFS-3 protocol standardization mailing list (afs3-standardization@openafs.org) as a recipient of any comments. | ||||||||||||||||
| draft-delord-pwe3-cw-bit-etree-07.txt | |||||||||||||||||
| Control Word Reserved bit for use in E-Tree | |||||||||||||||||
|
The extension described in this document allows a pair of PEs connected via an Ethernet Pseudowire (PW) to signal via the use of the Control Word (CW) whether the Ethernet frame encapsulated is coming from a Root AC or a Leaf AC. This allows a PE receiving this frame to decide whether it can be forwarded to a Leaf AC or not. Such forward or drop decision is an additional filtering action after the MAC-based forwarding decision. This applies to both P2P PW and P2MP PW. | ||||||||||||||||
| draft-demaria-dmm-dimensioning-considerations-00.txt | |||||||||||||||||
| Dimensioning considerations for distributed mobility architecture | |||||||||||||||||
|
One of the main questions posed during recent discussions on distributed mobility architectures is if the distributed architecture can have advantages in terms of costs with respect to a centralized one. This draft describes a general method to calculate the costs of the centralized and distributed scenarios. Even if a simplified model has been used, some information can be earned. Each operator can use this model and his own costs to discover the optimal architecture based on traffic observed in the network. | ||||||||||||||||
| draft-deng-softwire-aplusp-experiment-results-02.txt | |||||||||||||||||
| Implementing A+P in the provider's IPv6-only network | |||||||||||||||||
|
This memo describes an implementation of A+P in a provider's IPv6- only network. It provides details of the implementation, network elements, configurations and test results as well. Besides traditional port range A+P, a scattered port sets flavor of A+P is also implemented to verify feasibility of offering non-continuous port sets with A+P approach. The test results consist of the application compatibility test, UPnP 1.0 extensions and UPnP 1.0 friendly port allocation for A+P, port usage and BitTorrent behaviors with A+P. This memo focuses on the IPv6 flavor of A+P. | ||||||||||||||||
| draft-designteam-weirds-using-http-00.txt | |||||||||||||||||
| Using HTTP for RESTful Whois Services by Internet Registries | |||||||||||||||||
|
This document describes the use of HTTP in Whois services using RESTful web methodologies. | ||||||||||||||||
| draft-despres-6a44-01.txt | |||||||||||||||||
| Native IPv6 Behind NAT44 CPEs (6a44) | |||||||||||||||||
|
In customer sites having IPv4-only CPEs, Teredo provides a last resort IPv6 connectivity [RFC4380] [RFC5991] [RFC6081]. However, because it is designed to work without involvement of Internet service providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being base on ISP cooperation, avoids these limitations. 6a44 uses specific prefixes assigned by local ISPs (rather than the anycast address used by Teredo, an evolution similar to that from 6to4 to 6rd). The specification is complete enough for actual deployment, including with independently written codes. | ||||||||||||||||
| draft-despres-softwire-4rd-u-06.txt | |||||||||||||||||
| IPv4 Residual Deployment via IPv6 - Unified Solution (4rd) | |||||||||||||||||
|
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, customers can be assigned IPv4 addresses with restricted port sets. In some scenarios, 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of RFC6145). | ||||||||||||||||
| draft-despres-softwire-stateless-analysis-tool-01.txt | |||||||||||||||||
| Feature Analysis Tool for stateless IPv4/IPv6 (MAP-T,MAP-E,4rd) | |||||||||||||||||
|
This document proposes a discussion tool for the Softwire meeting at IETF 83 in Paris. Significant differentiating features between the MAP approach (proposed standards MAP-T and MAP-E) and the unified approach (proposed standard 4rd) are presented in tabular format. Its purpose is to facilitate decision making, and is therefore temporary. | ||||||||||||||||
| draft-detti-conet-ip-option-02.txt | |||||||||||||||||
| IPv4 and IPv6 Options to support Information Centric Networking | |||||||||||||||||
|
The Information Centric Networking (ICN) paradigm, shifts the focus of networking from providing connections between hosts to efficiently providing content to the users. The work on ICN has traditionally been performed looking at "clean-slate" solutions which aims to replace IP with a new paradigm. On the other hand, in this memo we propose an "integration" approach to Information Centric Networking, i.e. we extend the IP protocol using a new IP Option (both for IPv4 and IPv6). The new IP option is used by routers to support networking based on content rather than (or better in addition to) end-point addresses. | ||||||||||||||||
| draft-dhillon-ccamp-super-channel-ospfte-ext-03.txt | |||||||||||||||||
| 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]. | ||||||||||||||||
| draft-dhody-pce-bn-discovery-isis-04.txt | |||||||||||||||||
| ISIS Protocol Extensions for Boundary Node Discovery (BND) | |||||||||||||||||
|
There are various circumstances where it is highly desirable to be able to dynamically and automatically discover a set of Boundary Nodes (BN) along with their domain information. For that purpose, this document defines extensions to the Intermediate System to Intermediate System(IS-IS) routing protocol for the advertisement of Boundary Node (BN)Discovery information within an IS-IS area or within the entire IS-IS routing domain. | ||||||||||||||||
| draft-dhody-pce-bn-discovery-ospf-04.txt | |||||||||||||||||
| OSPF Protocol Extensions for Boundary Node Discovery (BND) | |||||||||||||||||
|
There are various circumstances where it is highly desirable to be able to dynamically and automatically discover a set of Boundary Nodes (BN) along with their domain information. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of Boundary Node (BN) Discovery information within an OSPF area or within the entire OSPF routing domain. | ||||||||||||||||
| draft-dhody-pce-cso-enabled-path-computation-01.txt | |||||||||||||||||
| Cross Stratum Optimization enabled Path Computation | |||||||||||||||||
|
Applications like cloud computing, video gaming, HD Video streaming, Live Concerts, Remote Medical Surgery, etc are offered by Data Centers. These data centers are geographically distributed and connected via a network. Many decisions are made in the Application space without any concern of the underlying network. Cross stratum application/network optimization focus on the challenges and opportunities presented by data center based applications and carriers networks together [CSO-DATACNTR]. Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. [RFC4655] explains the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document explains the architecture for CSO enabled Path Computation. | ||||||||||||||||
| draft-dhody-pce-pcep-domain-sequence-02.txt | |||||||||||||||||
| Standard Representation Of Domain Sequence | |||||||||||||||||
|
The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement for P2P and P2MP scenarios. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a standard representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain. This document also defines new sub-objects to be used to encode domain identifiers. | ||||||||||||||||
| draft-dhody-pce-pcep-ds-01.txt | |||||||||||||||||
| Encoding of Data Structure (DS) in the Path Computation Element Communication Protocol (PCEP) | |||||||||||||||||
|
The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement for P2P and P2MP scenarios. Backward-Recursive PCE-Based Computation (BRPC) [RFC5441] defines VSPT [Virtual Shortest Path Tree] as a default de-facto data structure for PCRep message in inter-domain scenarios. AS PCE will get used in newer scenarios like inter-domain, protection, P2MP etc. As well as PCE is being explored to be used in Cross Stratrum Optimization (CSO) environment (see [CSO-PCE]). Limiting PCEP protocol to just one data structure limits the usage of PCEP. Its important to keep PCEP generic enough to use differnt data structure and apply different algorithms. This document defines extensions to the PCE communication Protocol (PCEP) to allow multiple data structures. Extensions are defined for PCE to indicate the set of Data Structure (DS) it supports; also PCC/ PCE can indicate in a path computation request the required DS, and a PCE can report in a path computation reply the Data Structure that was used in the path reply message. | ||||||||||||||||
| draft-dhody-pce-pcep-p2mp-per-destination-01.txt | |||||||||||||||||
| Supporting explicit-path per destination in Path Computation Element Communication Protocol (PCEP) P2MP Path Request Message. | |||||||||||||||||
|
The ability to determine paths of point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) is one the key requirements for Path Computation Element (PCE). [RFC6006] and [PCE-P2MP-PROCEDURES] describes these mechanisms for intra and inter domain environment. Explicit Path in this document refers to the configured list of network elements that MUST be traversed or MUST be excluded in the final path computation. This should not be confused with the RSVP terminology. Network elements can further be strict or loose hop. This document describes extensions to the PCE communication Protocol (PCEP) to define explicit-path per destination in P2MP context. | ||||||||||||||||
| draft-dhody-pce-pcep-pathkey-mib-03.txt | |||||||||||||||||
| Management Information Base (MIB) for the PCE Communications Protocol (PCEP) for Path-Key based Confidentiality in Inter-Domain Path Computation. | |||||||||||||||||
|
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 the Path Computation Element communication Protocol (PCEP)for communications between a Path Computation Client (PCC)and a Path Computation Element (PCE), or between two PCEs when path-key- based confidentiality in inter-domain path computation is requested. | ||||||||||||||||
| draft-dhody-pce-pcep-service-aware-02.txt | |||||||||||||||||
| Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP). | |||||||||||||||||
|
In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency-Variation (jitter) and Packet loss is becoming a key requirement for path computation along with other constraints and metrics. Latency, Latency-Variation and Packet Loss is associated with the Service Level Agreement (SLA) between customers and service providers. [MPLS-DELAY-FWK] describes MPLS architecture to allow latency, loss and jittering as properties. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with which network performance information is distributed via OSPF and ISIS respectivily. This document describes the extension to PCEP to carry Latency, Latency-Variation and Loss as constraints for end to end path computation. | ||||||||||||||||
| draft-dickson-sidr-route-leak-def-01.txt | |||||||||||||||||
| Route Leaks -- Definitions | |||||||||||||||||
|
The Border Gateway Protocol, version 4, (BGP4) provides the means to advertise reachability for IP prefixes. This reachability information is propagated in a peer-to-peer topology. Sometimes routes are announced to peers for which the local peering policy does not permit. And sometimes routes are propagated indiscriminantly, once they have been accepted. This document considers the situations that can lead to routes being leaked, and tries to find acceptable definitions for describing these scenarios. The purpose of these definitions is to facilitate analysis of what a route leak is, and what the scope of the problem space for route leaks is. This, in turn, is intended to inform a requirements document for detection of (and prevention of) route leaks. And finally, the definitions and requirements are intended to allow proposed solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The fundamental objective is to "solve the route leaks problem". | ||||||||||||||||
| draft-dickson-sidr-route-leak-reqts-02.txt | |||||||||||||||||
| Route Leaks -- Requirements for Detection and Prevention thereof | |||||||||||||||||
|
The Border Gateway Protocol, version 4, (BGP4) provides the means to advertise reachability for IP prefixes. This reachability information is propagated in a peer-to-peer topology. Sometimes routes are announced to peers for which the local peering policy does not permit. And sometimes routes are propagated indiscriminantly, once they have been accepted. This document is a requirements document for detection of (and prevention of) route leaks. Together with the definitions document, it is intended to suggest solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The fundamental objective is to "solve the route leaks problem". | ||||||||||||||||
| draft-dickson-sidr-route-leak-solns-01.txt | |||||||||||||||||
| Route Leaks -- Proposed Solutions | |||||||||||||||||
|
The Border Gateway Protocol, version 4, (BGP4) provides the means to advertise reachability for IP prefixes. This reachability information is propagated in a peer-to-peer topology. Sometimes routes are announced to peers for which the local peering policy does not permit. And sometimes routes are propagated indiscriminantly, once they have been accepted. This document considers the situations that can lead to routes being leaked, and tries to find acceptable definitions for describing these scenarios. The purpose of these definitions is to facilitate discussion on what a route leak is, and what the scope of the problem space for route leaks is. This, in turn, is intended to inform a requirements document for detection of (and prevention of) route leaks. And finally, the definitions and requirements are intended to allow proposed solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The fundamental objective is to "solve the route leaks problem". | ||||||||||||||||
| draft-dijk-core-groupcomm-misc-00.txt | |||||||||||||||||
| 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 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. | ||||||||||||||||
| draft-djsmith-bgp-flowspec-oid-01.txt | |||||||||||||||||
| Revised Validation Procedure for BGP Flow Specifications | |||||||||||||||||
|
This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 requires that the originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP flow specifications. Though it is possible to disseminate such flow specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables flow specifications to be originated from a centralized BGP route controller. | ||||||||||||||||
| draft-dnoveck-nfsv4-migration-issues-02.txt | |||||||||||||||||
| NFSv4.0 migration: Implementation experience and spec issues to resolve | |||||||||||||||||
|
The migration feature of NFSv4 provides for moving responsibility for a single filesystem from one server to another, without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature. This document discusses the issues which have arisen and explores the options available for curing the issues via clarification and correction of the NFSv4.0 specification. | ||||||||||||||||
| draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-02.txt | |||||||||||||||||
| RSVP-TE Extensions for Lock Instruct and Loopback in MPLS Transport Profile | |||||||||||||||||
|
This document specifies extensions to RSVP-TE to support lock instruct and loopback mechanism for MPLS-TP LSPs. The mechanisms are intended to be applicable to other aspects of MPLS as well. | ||||||||||||||||
| draft-dong-idr-one-time-ext-community-orf-02.txt | |||||||||||||||||
| One-time Extended Community Based Outbound Route Filter for BGP-4 | |||||||||||||||||
|
This document defines a new Outbound Router Filter (ORF) type for BGP, termed "One-time Extended Community Outbound Route Filter", which would allow a BGP speaker to send to its BGP peer a route refresh request with a set of extended-community-based filters to make the peer re-advertise only the specific routes matching the filters to the speaker. This ORF-type enables a BGP speaker to refresh some specific routes without requiring its peer to re- advertise the whole Adj-RIB-Out, which makes the route refresh operation more efficient and reduces the impact on network stability. This filter does not change the outbound route filters on BGP peers and should only be used for one-time filtering. | ||||||||||||||||
| draft-dong-pwe3-mpls-tp-li-lb-00.txt | |||||||||||||||||
| LDP Extensions for Lock Instruct and Loopback of Pseudowire in MPLS Transport Profile | |||||||||||||||||
|
This document specifies extensions to the Label Distribution Protocol (LDP) to support provisioning of lock instruct and loopback mechanism for MPLS-TP Pseudowires. | ||||||||||||||||
| draft-dong-pwe3-redundancy-spe-01.txt | |||||||||||||||||
| Pseudowire Redundancy on S-PE | |||||||||||||||||
|
This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which the pseudowire redundancy is provided on the Switching-PE (S-PE). Signaling of preferential forwarding defined in [I-D.ietf-pwe3-redundancy-bit] is reused. | ||||||||||||||||
| draft-donley-behave-deterministic-cgn-02.txt | |||||||||||||||||
| Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments | |||||||||||||||||
|
Many Carrier Grade NAT solutions require per-connection logging. Unfortunately, such logging is not scalable to many residential broadband services. This document suggests a way to manage Carrier Grade NAT translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. | ||||||||||||||||
| draft-donley-dhc-cer-id-option-00.txt | |||||||||||||||||
| Customer Edge Router Identification Option | |||||||||||||||||
|
Several addressing mechanisms supporting DHCPv6 Prefix Delegation in home networks require identification of the customer edge router (CER) as the demarcation between the customer network and the service provider network. This document reserves a DHCPv6 option to identify the CER. | ||||||||||||||||
| draft-donley-nat444-impacts-04.txt | |||||||||||||||||
| Assessing the Impact of Carrier-Grade NAT on Network Applications | |||||||||||||||||
|
NAT444 is an IPv4 extension technology being considered by Service Providers to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Carrier-Grade NAT ("CGN") in the Service Provider network, often resulting in two NATs. CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment. This document identifies areas where adding a second layer of NAT disrupts the communication channel for common Internet applications. This document was updated to also include Dual-Stack Lite impacts. | ||||||||||||||||
| draft-donley-v6ops-ce-router-design-00.txt | |||||||||||||||||
| Design Considerations for an IPv6 CE Router | |||||||||||||||||
|
This document describes design considerations for IPv6 CE routers. | ||||||||||||||||
| draft-douglass-timezone-service-05.txt | |||||||||||||||||
| Timezone Service Protocol | |||||||||||||||||
|
This document defines a timezone service protocol that allows reliable, secure and fast delivery of timezone information to client systems such as calendaring and scheduling applications or operating systems. | ||||||||||||||||
| draft-drage-sipping-rfc3455bis-04.txt | |||||||||||||||||
| Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) | |||||||||||||||||
|
This document describes a set of private Session Initiation Protocol (SIP) header fields (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-header fields are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. | ||||||||||||||||
| draft-dreibholz-ipv4-flowlabel-15.txt | |||||||||||||||||
| An IPv4 Flowlabel Option | |||||||||||||||||
|
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. | ||||||||||||||||
| draft-dreibholz-rserpool-applic-distcomp-12.txt | |||||||||||||||||
| Applicability of Reliable Server Pooling for Real-Time Distributed Computing | |||||||||||||||||
|
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. | ||||||||||||||||
| draft-dreibholz-rserpool-applic-mobility-11.txt | |||||||||||||||||
| Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility | |||||||||||||||||
|
This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). | ||||||||||||||||
| draft-dreibholz-rserpool-asap-hropt-10.txt | |||||||||||||||||
| Handle Resolution Option for ASAP | |||||||||||||||||
|
This document describes the Handle Resolution option for the ASAP protocol. | ||||||||||||||||
| draft-dreibholz-rserpool-delay-09.txt | |||||||||||||||||
| Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling | |||||||||||||||||
|
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. | ||||||||||||||||
| draft-dreibholz-rserpool-enrp-takeover-07.txt | |||||||||||||||||
| Takeover Suggestion Flag for the ENRP Handle Update Message | |||||||||||||||||
|
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. | ||||||||||||||||
| draft-dreibholz-rserpool-score-10.txt | |||||||||||||||||
| Reliable Server Pooling (RSerPool) Bakeoff Scoring | |||||||||||||||||
|
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. | ||||||||||||||||
| draft-dreibholz-tsvwg-sctpsocket-multipath-03.txt | |||||||||||||||||
| SCTP Socket API Extensions for Concurrent Multipath Transfer | |||||||||||||||||
|
This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. | ||||||||||||||||
| draft-dreibholz-tsvwg-sctpsocket-sqinfo-03.txt | |||||||||||||||||
| Sender Queue Info Option for the SCTP Socket API | |||||||||||||||||
|
This document describes an extension to the SCTP sockets API for querying information about the sender queue. | ||||||||||||||||
| draft-droms-dhc-dhcpv6-solmaxrt-update-02.txt | |||||||||||||||||
| Modification to Default Value of SOL_MAX_RT | |||||||||||||||||
|
This document updates RFC 3315 by redefining the default value for SOL_MAX_RT and defining an option through which a DHCPv6 server can override the client's default value for SOL_MAX_RT with a new value. | ||||||||||||||||
| draft-dskoll-reputation-reporting-04.txt | |||||||||||||||||
| Reputation Reporting Protocol | |||||||||||||||||
|
This draft specifies a protocol for reporting various events associated with IP addresses. These events can be collected and aggregated to form a database containing information about the reputation of IP addresses. | ||||||||||||||||
| draft-dtnrg-ltp-cbhe-registries-02.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-duerst-eai-mailto-03.txt | |||||||||||||||||
| The 'mailto' URI/IRI Scheme | |||||||||||||||||
|
This document defines the format of Uniform Resource Identifiers (URIs) and Internationalized Resource Identfiers (IRIs) to identify resources that are reached using Internet mail. It adds the possibility to use Email Address Internationalization (EAI) email addresses (RFC6530) to the previous syntax of 'mailto' URIs (RFC 6068). | ||||||||||||||||
| draft-dugeon-pce-ted-reqs-01.txt | |||||||||||||||||
| Path Computation Element (PCE) Traffic Engineering Database (TED) Requirements | |||||||||||||||||
|
The Path Computation Element (PCE) working group (WG) has produced a set of RFCs to standardize the behavior of the Path Computation Element as a tool to help MPLS-TE and GMPLS LSP tunnels placement. In the PCE architecture, a main assumption has been done concerning the information that the PCE needs to perform its computation: the Traffic Engineering Database (TED) contains all pertinent and suitable information regarding the network that is in the scope of a PCE. Nevertheless, the TED requirements as well as the TED information have not yet been formalized. In addition, some recent RFC (like the Backward Recursive Path Computation procedure) or WG draft (like draft-ietf-pce-hierarchy ...) suffer from a lack of information in the TED, leading to a non optimal result or to some difficulties to deploy them. This memo tries to identity some TED requirements for the PCE. It is split in two main section: the identification of the specific information to be stored in the TED and how it may be populated. | ||||||||||||||||
| draft-duker-as2-reliability-11.txt | |||||||||||||||||
| Operational Reliability for EDIINT AS2 | |||||||||||||||||
|
The goal of this document is to define approaches to achieve a "once and only once" delivery of messages. The EDIINT AS2 protocol [AS2] is implemented by a number of software tools on a variety of platforms with varying capabilities and with varying network service quality. Although the AS2 protocol defines a unique "Message-ID", current implementations of AS2 do not provide a standard method to prevent the same message (re-transmitted by the initial sender) from reaching back-end business applications at the initial receiver. TCP underpinnings of HTTP over which AS2 operates generally provide a good quality of network connectivity, but experience indicates a need to be able to compensate for both transient server and socket exceptions, including "Connection refused" as well as "Server busy." In addition, difficulties with server availability, stability, and loads can result in reduced operational reliability. This document describes some ways to compensate for exceptions and enhance the reliability of AS2 protocol operation. Implementation of these reliability features is indicated by presence of the "AS2- Reliability" value in the EDIINT-Features header. Intended Status The intent of this document is to be placed on the RFC track as an Informational RFC. Feedback Instructions: NOTE TO RFC EDITOR: This section should be removed by the RFC editor prior to publication. If you want to provide feedback on this draft, follow these guidelines: -Send feedback via e-mail to the ietf-ediint list for discussion, with "AS2 Reliability" in the Subject field. To enter or follow the discussion, you need to subscribe to ietf-ediint@imc.org. -Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. -If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. | ||||||||||||||||
| draft-dunbar-armd-arp-nd-scaling-bcp-00.txt | |||||||||||||||||
| BCP for ARP-ND Scaling for Large Data Centers | |||||||||||||||||
|
This draft is intended to document some simple well established practices which can scale ARP/ND in data center environment. | ||||||||||||||||
| draft-dunbar-trill-directory-assisted-edge-05.txt | |||||||||||||||||
| Directory Assisted RBridge Edge | |||||||||||||||||
|
RBridge edge nodes currently learn the mapping between MAC addresses and their corresponding RBridge edge nodes by observing the data packets traversed through. When ingress RBridge receives a data packet with its destination address (MAC&VLAN) unknown, the data packet is flooded across RBridge domain. When there are more than one RBridge ports connected to one bridged LAN, only one of them can be designated as AF port for forwarding/receiving traffic for each LAN, the rest have to be blocked for that LAN. This draft describes the framework of using directory assisted RBridge edge to improve TRILL network scalability in data center environment. | ||||||||||||||||
| draft-dunbar-trill-scheme-for-directory-assist-00.txt | |||||||||||||||||
| Mechanisms for Directory Assisting RBridge | |||||||||||||||||
|
This draft describes the mechanisms of using directory server(s) to assist RBridge edge in data center environment. | ||||||||||||||||
| draft-dupont-pcp-dslite-02.txt | |||||||||||||||||
| The Port Control Protocol in Dual-Stack Lite environments | |||||||||||||||||
|
This document specifies the so-called "plain mode" for the use of the Port Control Protocol (PCP) in Dual-Stack Lite (DS-Lite) environments. | ||||||||||||||||
| draft-dvir-roll-security-authentication-01.txt | |||||||||||||||||
| Version Number and Rank Authentication | |||||||||||||||||
|
Designing a routing protocol for large low-power and lossy networks (LLNs), consisting of thousands of constrained nodes and unreliable links, presents new challenges. The IPv6 Routing Protocol for Low- power and Lossy Networks (RPL), have been developed by the IETF ROLL Working Group as a preferred routing protocol to provide IPv6 routing functionality in LLNs. Unfortunately, the currently available security services in RPL will not protect against a compromised internal node that can construct and disseminate fake messages. Therefore, in RPL special security care must be taken when the Destination Oriented Directed Acyclic Graph (DODAG) root is updating the Version Number by which reconstruction of the routing topology can be initiated. The same care also must be taken to prevent an internal attacker (compromised DODAG node) to publish decreased Rank value, which causes a large part of the DODAG to connect to the DODAG root via the attacker and give it the ability to eavesdrop or manipulate a large part of the network traffic. In this document, a new security service is described that prevents any misbehaving DODAG node from illegitimately increasing the Version Number or publish illegitimately decreased Rank values. | ||||||||||||||||
| draft-dykim-nara-00.txt | |||||||||||||||||
| Network Architecture with Recursive Addressing | |||||||||||||||||
|
A network architecture based on recursive addressing is proposed. The Internet is modeled as a network of autonomous sites, each being a collection of nodes. Each site is named by a site address drawn from a global number space while each node is named by a node address drawn from a number space local to each site. Routing among sites depends solely on site addresses while that within each site on node addresses. Flat routing to render inherent mobility as well as mapped routing to additionally cope with table size are proposed. The model can recursively repeat itself both outwards and inwards in the network, enabling its applicability, for example, to inter- planetary as well as body area networks. | ||||||||||||||||
| draft-dykim-recursive-addressing-00.txt | |||||||||||||||||
| NARA : Network Architecture with Recursive Addressing | |||||||||||||||||
|
This document describes network architecture based on recursive addressing. The Internet is modeled as a network of autonomous sites, each being a collection of nodes. Each site is named by a site address drawn from a global number space while each node is named by a node address drawn from a number space local to each site. Routing among sites depends solely on site addresses while that within each site on node addresses. Flat routing to render inherent mobility as well as mapped routing to additionally cope with table size are proposed. The model can recursively repeat itself both outwards and inwards in the network, enabling its applicability, for example, to inter-planetary as well as body area networks. | ||||||||||||||||
| draft-eastlake-fnv-03.txt | |||||||||||||||||
| The FNV Non-Cryptographic Hash Algorithm | |||||||||||||||||
|
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community. | ||||||||||||||||
| draft-eastlake-isis-rfc6326bis-07.txt | |||||||||||||||||
| Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS | |||||||||||||||||
|
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology, and support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL. This document obsoletes RFC 6326. | ||||||||||||||||
| draft-eastlake-trill-lldp-00.txt | |||||||||||||||||
| Transparent Interconnection of Lots of Links (TRILL) Support of the Link Layer Discover Protocol (LLDP) | |||||||||||||||||
|
The Link Layer Discovery Protocol (LLDP, IEEE Std 802.1AB) is a one- way, unacknowledged protocol for the announcement of a station's capabilities to its peers. The set of peers that receive these frames and the scoping of the frame, such as whether or not it traverses certain types of bridges, is primarily determined by the destination MAC address of the LLDP frame. This document specifies TRILL (Transparent Interconnection of Lots of Links) support of LLDP and updates RFC 6325. | ||||||||||||||||
| draft-eastlake-trill-rbridge-dcb-03.txt | |||||||||||||||||
| RBridges: Support of IEEE 802.1Qbb,802.1Qaz,and 802.1Qau | |||||||||||||||||
|
IEEE 802.1 has developed standards as part of its Data Center Bridging (DCB) activity to (1) efficiently minimize data loss due to queue overflow for selected classes of traffic within Local Area Networks (LANs) meeting certain conditions and (2) provide means to allocate the available bandwidth on links to different classes of traffic. These standards were adopted as the IEEE 802.1Qbb, 802.1Qaz, and 802.1Qau amendmenst to the 802.1Q standard. This document briefly explains the standards and discusses the support of these IEEE 802 standards in RBridges (devices that implement the IETF TRILL standard). | ||||||||||||||||
| draft-eastlake-trill-rbridge-multi-topo-02.txt | |||||||||||||||||
| Multiple Topology TRILL | |||||||||||||||||
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol is a solution for least cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using IS-IS (Intermediate System to Intermediate System) link-state routing and encapsulation with a hop count. IS-IS supports multiple topology routing. This document specifies a TRILL data plane encoding and procedures to make use of such routing. | ||||||||||||||||
| draft-eddy-tsvwg-saratoga-tfrc-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-edwards-telnet-xon-xoff-state-control-00.txt | |||||||||||||||||
| Xon/Xoff State Control for Telnet Com Port Control Option | |||||||||||||||||
|
This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server. | ||||||||||||||||
| draft-elwell-mmusic-ice-updated-offer-02.txt | |||||||||||||||||
| ICE Updated Offer Problematic | |||||||||||||||||
|
Interactive Connectivity Establishment (ICE) requires an updated offer-answer cycle under some circumstances, to satisfy the needs of some devices on the signalling path. When used with SIP, this additional offer-answer cycle interacts with other things, such as fax and third party call control (3PCC). This document describes the problems and discusses possible remedies. This work is being discussed on the mmusic@ietf.org mailing list. | ||||||||||||||||
| draft-enyedi-rtgwg-mrt-frr-algorithm-01.txt | |||||||||||||||||
| Algorithms for computing Maximally Redundant Trees for IP/LDP Fast- Reroute | |||||||||||||||||
|
A complete solution for IP and LDP Fast-Reroute using Maximally Redundant Trees is presented in [I-D.ietf-rtgwg-mrt-frr- architecture]. This document describes an algorithm that can be used to compute the necessary Maximally Redundant Trees and the associated next-hops. | ||||||||||||||||
| draft-ermagan-lisp-nat-traversal-01.txt | |||||||||||||||||
| NAT traversal for LISP | |||||||||||||||||
|
This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by a new network element, the LISP Re-encapsulating Tunnel Router (RTR), which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT. | ||||||||||||||||
| draft-eubanks-mboned-transition-overview-04.txt | |||||||||||||||||
| Multicast Transition Overview | |||||||||||||||||
|
IPTV providers must serve content to their customers during the period of transition from IPv4 to IPv6. During this period, the content provider may support only one version of IP while the customer's receiver device supports only the other. Likewise, the network between the provider and its customer may include segments supporting only one version of IP or another. This document provides an overview of the multicast transition problem. It also provides an overview of the solution space. The solution space is characterized by an adaptation function (AF) that provides an interface between IPv4 and IPv6 multicast domains. This document also discusses various multicast use cases which may occur during IPv6 transitioning. These use cases motivate the solution space discussion and the requirements that appear at the end. | ||||||||||||||||
| draft-even-clue-rtp-mapping-01.txt | |||||||||||||||||
| Mapping RTP streams to CLUE media captures | |||||||||||||||||
|
This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. | ||||||||||||||||
| draft-evil-self-destruct-ach-code-point-00.txt | |||||||||||||||||
| Allocation of an Associated Channel Code Point for Use by ISOEG Self- Destruct OAM | |||||||||||||||||
|
This document assigns an Associated Channel Type code point for carrying Self-Destruct Operations, Administration, and Management messages in the MPLS Generic Associated Channel (G-ACh). | ||||||||||||||||
| draft-ezy-mpls-1ton-protection-01.txt | |||||||||||||||||
| MPLS-TP 1toN Protection | |||||||||||||||||
|
As part of the Transport Profile for Multiprotocol Label Switching (MPLS-TP) there is a requirement to support 1:n linear protection for transport paths. This requirement is elaborated on in the MPLS-TP Survivability Framework document [SurvivFwk]. The basic protocol for linear protection was specified in the MPLS-TP Linear Protection document [LinProt] but is limited to 1+1 and 1:1 protection. This document extends the protocol defined there to address the additional functionality necessary to support scenarios of a single protection path preconfigured to provide protection of multiple transport paths between two joint endpoints. 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. | ||||||||||||||||
| draft-fairhurst-tcpm-newcwv-02.txt | |||||||||||||||||
| Updating TCP to support Variable-Rate Traffic | |||||||||||||||||
|
This document addresses issues that arise when TCP is used to support variable-rate traffic that exhibts periods where the transmission rate is limited by the application rather than the congestion window. It updates TCP to allow a TCP sender to restart quickly following either an idle or applications-limited interval. The method is expected to benefit variable-rate TCP applications, while also providing an appropriate response if congestion is experienced. The document also evaluates TCP Congestion Window Validation (CWV), an IETF experimental specification defined in RFC 2861, and concludes that CWV sought to address important issues, but failed to deliver a widely used solution. This document recommends that the IETF should consider moving RFC 2861 from Experimental to Historic status, and that this is replaced by the current specification. | ||||||||||||||||
| draft-fan-opsawg-transmission-interuption-00.txt | |||||||||||||||||
| Requirements for IP/MPLS network transmission interruption duration | |||||||||||||||||
|
The transmission performance of IP/MPLS network affects upper layer services and networks, but there is no consensus in the industry on transmission interruption for IP/MPLS network up to now. This memo studies requirements for the interruption duration criteria in several service scenarios. | ||||||||||||||||
| draft-fanf-dane-smtp-00.txt | |||||||||||||||||
| Secure inter-domain SMTP with TLS,DNSSEC and TLSA records. | |||||||||||||||||
|
SMTP supports STARTTLS for inter-domain mail transfer, but it only provides very limited security because the server's certificate cannot be authenticated. This memo specifies how TLSA records in the DNS can be used for proper MX target server authentication. | ||||||||||||||||
| draft-farinacci-lisp-lcaf-07.txt | |||||||||||||||||
| LISP Canonical Address Format (LCAF) | |||||||||||||||||
|
This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. | ||||||||||||||||
| draft-farinacci-lisp-rig-00.txt | |||||||||||||||||
| LISP-DDT Referral Internet Groper (RIG) | |||||||||||||||||
|
A simple tool called the LISP-DDT Referral Internet Groper or 'rig' can be used to query the LISP-DDT hierarchy. This draft describes how the 'rig' tool works. | ||||||||||||||||
| draft-farinacci-lisp-te-00.txt | |||||||||||||||||
| LISP Traffic Engineering Use-Cases | |||||||||||||||||
|
This document describes how LISP re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. | ||||||||||||||||
| draft-farrell-decade-ni-06.txt | |||||||||||||||||
| Naming Things with Hashes | |||||||||||||||||
|
This document defines a set of ways to identify a thing using the output from a hash function, specifying URI, URL, binary and human "speakable" formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object such that the referenced object may be authenticated to the same degree as the reference to it. | ||||||||||||||||
| draft-farrell-dtnrg-bpq-01.txt | |||||||||||||||||
| Bundle Protocol Query Extension Block | |||||||||||||||||
|
The Bundle Protocol (BP) provides store-and-forward networking for Delay- and Disruption-Tolerant Networks. This document defines the BP query extension block (BPQ) which allows applications to query the stores of nodes on the path along which a bundle containing a bundle query extension block is routed. | ||||||||||||||||
| draft-farrell-kc-01.txt | |||||||||||||||||
| Public Key Checking Protocol | |||||||||||||||||
|
Some asymmetric key generation implementations do not use sufficient randomness giving rise to a number of bad public keys, for example with known factors, being used on the Internet. This memo specifies [[for now: just outlines]] an experimental protocol that could be used by a private key holder to talk to a responder that knows the values of (some of) those bad keys that have been seen in the wild. The protocol only allows a holder of the relevant private key to request information, as doing otherwise could weaken the overall security of the Internet and also considers confidentiality and privacy as important requirements, as information that a given bad public key is associated with a particular identifier could also weaken the security of the Internet. | ||||||||||||||||
| draft-farrkingel-ccamp-flexigrid-lambda-label-03.txt | |||||||||||||||||
| Generalized Labels for the Flexi-Grid in Lambda-Switch-Capable (LSC) Label Switching Routers | |||||||||||||||||
|
A new flexible wavelength grid ("flexi-grid") is being developed within the ITU-T Study Group 15 to allow selection and switching of individual lambdas chosen flexibly from a detailed, fine granularity grid of available wavelengths. This document updates the definition of GMPLS lambda labels to support the flexi-grid. This document updates RFC 3471 and updates RFC 6205. | ||||||||||||||||
| draft-fastenrath-ethics-search-protocol-00.txt | |||||||||||||||||
| Ethics Search Protocol (ESP) for Internet Search Engines | |||||||||||||||||
|
This document contains a specification for imprints, ethical policies and social contracts, the annotation of these, as well as the annotation of arbitrary content that can be referenced by fully qualified URIs, the submission of digitally signed tickets concerning imprints, ethical policies, social contracts or annotations, and a search interface for internet search engines. | ||||||||||||||||
| draft-fleischhauer-ipv4-addr-saving-02.txt | |||||||||||||||||
| On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios | |||||||||||||||||
|
Today the Dual-Stack approach is the most straightforward and the most common way for introducing IPv6 into existing systems and networks. However a typical drawback of implementing Dual-Stack is that each node will still require at least one IPv4 address. Hence, solely deploying Dual-Stack does not provide a sufficient solution to the IPv4 address exhaustion problem. Assuming a situation where most of the IP communication (e.g. always-on, VoIP etc.) can be provided via IPv6, the usage of public IPv4 addresses can significantly be reduced and the unused public IPv4 addresses can under certain circumstances be returned to the public IPv4 address pool of the service provider. New Dual-Stack enabled services can be introduced without increasing the public IPv4 address demand, when IPv6 will be the preferred network layer protocol. This document describes such a solution in a Dual-Stack PPP session network scenario and explains the protocol mechanisms which are used. | ||||||||||||||||
| draft-foo-v6ops-6rdmtu-00.txt | |||||||||||||||||
| 6rd Tunnel MTU | |||||||||||||||||
|
The 6rd tunnel MTU is currently recommended to be set to 1480. This is to avoid IPv4 fragmentation within the tunnel, but requires the 6rd tunnel ingress interface to drop any IPv6 packet larger than 1480 bytes and return an ICMPv6 Packet Too Big (PTB) message. Concerns for operational issues with both IPv4 and IPv6 Path MTU Discovery point to the possibility of MTU-related black holes when a packet is dropped due to an MTU restriction, so dropping packets is considered highly undesirable. Fortunately, the "Internet cell size" is 1500 bytes, i.e., the minimum MTU configured by the vast majority of links in the Internet. This document therefore presents a method to boost the 6rd MTU to 1500 bytes. | ||||||||||||||||
| draft-forte-ecrit-service-classification-03.txt | |||||||||||||||||
| Labels for Common Location-Based Services | |||||||||||||||||
|
This document creates a registry for describing the types of services available at a specific location. The registry is expected to be referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). | ||||||||||||||||
| draft-forte-service-classification-00.txt | |||||||||||||||||
| Labels for Common Location-Based Services | |||||||||||||||||
|
This document creates a registry for describing the types of services available at a specific location. The registry is expected to be referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). | ||||||||||||||||
| draft-fossati-core-multipart-ct-00.txt | |||||||||||||||||
| Multipart Media Type Encoding for CoAP | |||||||||||||||||
|
This memo defines a new media type encoding that can be used to combine several different media types into a single CoAP message- body. | ||||||||||||||||
| draft-fossati-core-publish-monitor-options-01.txt | |||||||||||||||||
| Publish and Monitor Options for CoAP | |||||||||||||||||
|
This memo defines two additional Options for the Constrained Application Protocol (CoAP) especially targeted at sleepy sensors: Publish and Monitor. The Publish Option enables opportunistic updates of a given resource state, by temporarily delegating the authority of the Publish'ed resource to a Proxy node. The whole process is driven by the (sleepy) origin -- which may actually never need to listen. The Monitor Option complements the typical Observe pattern, enabling the tracking of a resource hosted by a node sleeping most of the time, by taking care of establishing and maintaining an Observe relationship with the (sleepy) origin on behalf of the (sleepy) client. | ||||||||||||||||
| draft-freedman-l3vpn-ospf2-4364-ce-00.txt | |||||||||||||||||
| OSPF Version 2 as the Customer Edge/Customer Protocol for BGP/MPLS IP VPNs | |||||||||||||||||
|
RFC4577 (OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs) proposes a mechanism for the use of the Open Shortest Path First V2 ("OSPF", RFC2328) protocol between the Provider Edge ("PE") and Customer Edge ("CE") routers within a BGP/MPLS IP Virtual Private Network ("IP/VPN", RFC4364). The standard provides for use of such a provider VPN to join discontiguous locations together, preserving the OSPF area and domain behaviour. This document describes a technique for utilising the same, IPVPN network infrastructure without the requirement to enable the OSPF protocol on the PE/CE interface and thus relieve the PE router of OSPF duties. | ||||||||||||||||
| draft-freeman-plasma-requirements-01.txt | |||||||||||||||||
| 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 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 doing/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. | ||||||||||||||||
| draft-fu-softwire-4rd-mib-00.txt | |||||||||||||||||
| Definitions of Managed Objects for 4rd | |||||||||||||||||
|
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 managed objects for 4rd. | ||||||||||||||||
| draft-fu-softwire-dslite-mib-04.txt | |||||||||||||||||
| DS-Lite 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 defines managed objects for DS-Lite. | ||||||||||||||||
| draft-fu-softwire-map-mib-00.txt | |||||||||||||||||
| Definitions of Managed Objects for MAP-E | |||||||||||||||||
|
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 managed objects for MAP-E. | ||||||||||||||||
| draft-fuller-lisp-ddt-01.txt | |||||||||||||||||
| LISP Delegated Database Tree | |||||||||||||||||
|
This draft describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. | ||||||||||||||||
| draft-fuxh-mpls-delay-loss-te-framework-05.txt | |||||||||||||||||
| Loss and Delay Traffic Engineering Framework for MPLS | |||||||||||||||||
|
With more and more enterprises using cloud based services, the distances between the user and the applications are growing. A lot of the current applications are designed to work across LAN's and have various inherent assumptions. For multiple applications such as High Performance Computing and Electronic Financial markets, the response times are critical as is packet loss, while other applications require more throughput. [RFC3031] describes the architecture of MPLS based networks. This draft extends the MPLS architecture to allow for latency, loss and jitter as properties. It describes requirements and control plane implication for latency and packet loss as a traffic engineering performance metric in today's network which is consisting of potentially multiple layers of packet transport network and optical transport network in order to make a accurate end-to-end latency and loss prediction before a path is established. Note MPLS architecture for Multicast will be taken up in a future version of the draft. | ||||||||||||||||
| draft-g-698-2-lmp-00.txt | |||||||||||||||||
| Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage black-link optical interface parameters of DWDM application | |||||||||||||||||
|
This memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems or characterized by the Optical Transport Network (OTN) in accordance with the Black-Link approach defined in ITU-T Recommendation G.698.2[ITU.G698.2].[ITU.G698.2] | ||||||||||||||||
| draft-galimbe-kunze-g-698-2-snmp-mib-02.txt | |||||||||||||||||
| A SNMP MIB to manage black-link optical interface parameters of DWDM applications | |||||||||||||||||
|
This memo defines a portion of the Management Information Base (MIB) used by Simple Network Management Protocol (SNMP) in TCP/IP- based internets. In particular, it defines objects for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems or characterized by the Optical Transport Network (OTN) in accordance with the Black-Link approach defined in ITU-T Recommendation G.698.2. [ITU.G698.2] The MIB module defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of Black Links. | ||||||||||||||||
| draft-garcia-core-security-04.txt | |||||||||||||||||
| Security Considerations in the IP-based Internet of Things | |||||||||||||||||
|
A direct interpretation of the Internet of Things concept refers to the usage of standard Internet protocols to allow for human-to-thing or thing-to-thing communication. Although the security needs are well-recognized, it is still not fully clear how existing IP-based security protocols can be applied to this new setting. This Internet-Draft first provides an overview of security architecture, its deployment model and general security needs in the context of the lifecycle of a thing. Then, it presents challenges and requirements for the successful roll-out of new applications and usage of standard IP-based security protocols when applied to get a functional Internet of Things. | ||||||||||||||||
| draft-garcia-martinez-cgamib-04.txt | |||||||||||||||||
| Management Information Base for Cryptographically Generated Addresses (CGA) | |||||||||||||||||
|
This memo defines a portion of the Management Information Base (MIB) for managing Cryptographically Generated Addresses (CGA). | ||||||||||||||||
| draft-garcia-martinez-sendmib-04.txt | |||||||||||||||||
| Management Information Base for the SEcure Neighbor Discovery (SEND) protocol | |||||||||||||||||
|
This memo defines a portion of the Management Information Base (MIB) for managing the SEND (SEcure Neighbor Discovery) Protocol. | ||||||||||||||||
| draft-garcia-mmusic-sdp-miscellaneous-caps-01.txt | |||||||||||||||||
| Miscellanoues 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). | ||||||||||||||||
| draft-gashinsky-6man-v6nd-enhance-00.txt | |||||||||||||||||
| Neighbor Discovery Enhancements for DOS mititgation | |||||||||||||||||
|
In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery can be vulnerable to denial of service attacks whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools that scan networks for inventory and other purposes. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing ipv6 transported flows may be interrupted. This document describes possible modifications to the traditional [RFC4861] neighbor discovery protocol for improving the resilience of the neighbor discovery process as well as an alternative method for maintaining ND caches. | ||||||||||||||||
| draft-generic-v6ops-tunmtu-01.txt | |||||||||||||||||
| Generic Tunnel MTU Determination | |||||||||||||||||
|
The tunnel MTU for popular IP-in-IP tunneling mechanisms is currently recommended to be set to 1500 (or less) minus the length of the encapsulation headers when static MTU determination is used. This is to avoid IP fragmentation within the tunnel, but requires the tunnel ingress to either fragment any IP packet larger than the MTU or drop the packet and return an ICMP Packet Too Big (PTB) message. Concerns for operational issues with both IPv4 and IPv6 Path MTU Discovery point to the possibility of MTU-related black holes when a packet is dropped due to an MTU restriction. Fortunately, the "Internet cell size" is 1500 bytes, i.e., the minimum MTU configured by the vast majority of links in the Internet. We also note that these same considerations apply to the encapsulation of any combination of IP- within-IP protocol versions. This document therefore presents a method to boost the tunnel MTU to larger values. | ||||||||||||||||
| draft-gennai-appsawg-cem-01.txt | |||||||||||||||||
| Certified Electronic Mail | |||||||||||||||||
|
This document specifies the requirements for a Certified Electronic Mail (CEM) system which provides people with proof of communication when exchanging emails, giving strong evidences to the users involved in the interchange. | ||||||||||||||||
| draft-george-ipv6-support-01.txt | |||||||||||||||||
| IPv6 Support Within IETF work | |||||||||||||||||
|
This document recommends that IETF formally require its standards work to be IP version agnostic or to explicitly include support for IPv6, with some exceptions. It recommends that future IPv4 work be limited to solving documented operational problems identified through deployment experience. | ||||||||||||||||
| draft-georgiades-opsawg-intercar-oam-req-02.txt | |||||||||||||||||
| 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. This document specifies additional requirements for the inter-carrier OAM operations. | ||||||||||||||||
| draft-gersch-dnsop-revdns-cidr-02.txt | |||||||||||||||||
| Reverse DNS Naming Convention for CIDR Address Blocks | |||||||||||||||||
|
The reverse DNS naming method is used to specify a complete IP address. At present there is no standard way for the reverse DNS to handle address ranges. As an example, there is no formal mechanism to define a reverse DNS name for the block of addresses specified by the IPv4 prefix 129.82.0.0/16. Defining such a reverse DNS naming convention would be useful for a number of applications. This draft proposes a naming convention for encoding CIDR address blocks into the reverse DNS namespace. | ||||||||||||||||
| draft-gersch-grow-revdns-bgp-00.txt | |||||||||||||||||
| DNS Resource Records for BGP Routing Data | |||||||||||||||||
|
This draft proposes the creation of two DNS record types for storing BGP routing information in the reverse DNS. The RLOCK record allows prefix owners to indicate whether the DNS is being used to publish routing data. The SRO record allows operators to indicate whether an IPv4 or IPv6 prefix ought to appear in global routing tables and identifies authorized origin Autonomous System Number(s) for that prefix. The published data can be used in a variety of contexts and can be extended to include additional information. This work is part of an on-going effort and is accessible in an active testbed. | ||||||||||||||||
| draft-giacomin-core-sleepy-option-00.txt | |||||||||||||||||
| Sleepy Option for CoAP | |||||||||||||||||
|
This memo defines a framework for allowing asynchronous communication between sleepy sensors mediated by a supporting Proxy node. The Proxy acts as a store-and-forward agent that handles requests on behalf of a sleepy client, and buffers responses coming from the target origin until the requesting client wakes up and get the computation results. A new CoAP option, Sleepy, is defined to initiate and control the asynchronous exchange. | ||||||||||||||||
| draft-gieben-nsec4-00.txt | |||||||||||||||||
| DNS Security (DNSSEC) Authenticated Denial of Existence | |||||||||||||||||
|
The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record for authenticated denial of existence, and the NSEC3 resource record for hashed authenticated denial of existence. This document introduces an alternative resource record, NSEC4, which similarly provides authenticated denial of existence. It permits gradual expansion of delegation-centric zones, just like NSEC3 does. With NSEC4 it is possible, but not required, to provide measures against zone enumeration. NSEC4 reduces the size of the denial of existence response and adds Opt-Out to unhashed names. | ||||||||||||||||
| draft-gmann-homenet-relay-autoconf-01.txt | |||||||||||||||||
| Home Network Autoconfiguration via DHCPv6 Relay | |||||||||||||||||
|
This document describes a method for efficiently delegating subnets of an IPv6 prefix among home routers while simultaneously creating functional routing tables in all home routers without the need for a routing protocol. | ||||||||||||||||
| draft-gnawali-roll-rpl-recommendations-03.txt | |||||||||||||||||
| Recommendations for Efficient Implementation of RPL | |||||||||||||||||
|
RPL is a flexible routing protocol applicable to a wide range of Low Power and Lossy Networks. To enable this wide applicability, RPL provides many configuration options and gives implementers choices on how to implement various components of RPL. Drawing on our experiences, we distill the design choices and configuration parameters that lead to efficient RPL implementations and operations. | ||||||||||||||||
| draft-godgrey-dtg-urn-01.txt | |||||||||||||||||
| A URN Namespace for Digital Television Group (DTG) | |||||||||||||||||
|
This document describes a Uniform Resource Name (URN) namespace which is maintained by the Digital Television Group (DTG) for naming persistent resources (specifically, various DTG specifications). | ||||||||||||||||
| draft-goix-appsawg-enum-sn-service-01.txt | |||||||||||||||||
| ENUM Service Registration for Social Networking (SN) Services | |||||||||||||||||
|
This document registers a Telephone Number Mapping (ENUM) service for Social Networking (SN). Specifically, this document focuses on provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM. | ||||||||||||||||
| draft-golovinsky-cloud-services-log-format-02.txt | |||||||||||||||||
| Syslog Extension for Cloud Using Syslog Structured Data | |||||||||||||||||
|
This document provides an open and extensible log format to be used by any cloud entity or cloud application to log and trace activities that occur in the cloud. The logs and traces can be utilized for billing, charging, and debugging purposes. In addition, these logs and traces are equally applicable for cloud infrastructure (IaaS), platform (PaaS), and application (SaaS) services. CloudLog is different in content, but not in nature from the traditional logging as it takes in account transient nature of Identities and resources in the cloud. | ||||||||||||||||
| draft-gondrom-frame-options-02.txt | |||||||||||||||||
| HTTP Header Frame Options | |||||||||||||||||
|
To improve the protection of web applications against Cross Site Request Forgery (CSRF) and Clickjacking this standards defines a http response header that declares a policy communicated from a host to the client browser whether the transmitted content MUST NOT be displayed in frames of other pages from different origins or a list of trusted origins which are allowed to frame the content. | ||||||||||||||||
| draft-gondrom-websec-csp-header-00.txt | |||||||||||||||||
| HTTP Header Content Security Policy | |||||||||||||||||
|
To communicate the Content Security Policy (CSP) as defined by the W3C, the web server needs to send a HTTP header to the browser (client) to inform it about the content security policies that SHALL be applied on the client. This draft outlines the header to communicate the CSP with its fields. The definition of the semantic of the directives will be done by the Web Application Security Working Group at the W3C. | ||||||||||||||||
| draft-gondrom-x-frame-options-00.txt | |||||||||||||||||
| HTTP Header X-Frame-Options | |||||||||||||||||
|
To improve the protection of web applications against Cross Site Request Forgery (CSRF) and Clickjacking this standards defines a http response header that declares a policy communicated from a host to the client browser whether the transmitted content MUST NOT be displayed in frames of other pages from different origins or a list of trusted origins which are allowed to frame the content. This drafts serves to document the existing use and specification of X-Frame-Options. | ||||||||||||||||
| draft-gont-6man-flowlabel-security-03.txt | |||||||||||||||||
| Security Assessment of the IPv6 Flow Label | |||||||||||||||||
|
This document discusses the security implications of the IPv6 "Flow Label" header field, and analyzes possible schemes for selecting the Flow Label value of IPv6 packets. | ||||||||||||||||
| draft-gont-6man-ipv6-atomic-fragments-00.txt | |||||||||||||||||
| Processing of IPv6 "atomic" fragments | |||||||||||||||||
|
IPv6 allows packets to contain a Fragment Header, without the packet being actually fragmented into multiple pieces. Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by hosts as "fragmented traffic". By forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and the launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that the attack vector based on "atomic fragments" is completely eliminated. | ||||||||||||||||
| draft-gont-6man-ipv6-smurf-amplifier-00.txt | |||||||||||||||||
| Security Implications of IPv6 options of Type 10xxxxxx | |||||||||||||||||
|
When an IPv6 node processing an IPv6 packet does not support an IPv6 option whose two-highest-order bits of the Option Type are '10', it is required to respond with an ICMPv6 Parameter Problem error message, even if the Destination Address of the packet was a multicast address. This feature provides an amplification vector, opening the door to an IPv6 version of the 'Smurf' Denial-of-Service (DoS) attack found in IPv4 networks. This document discusses the security implications of the aforementioned options, and formally updates RFC 2460 such that this attack vector is eliminated. Additionally, it describes a number of operational mitigations that could be deployed against this attack vector. | ||||||||||||||||
| draft-gont-6man-managing-slaac-policy-00.txt | |||||||||||||||||
| Managing the Address Generation Policy for Stateless Address Autoconfiguration in IPv6 | |||||||||||||||||
|
This document describes an operational problem that arises due to the impossibility of managing the address generation policy employed by hosts participating in IPv6 Stateless Address Autoconfiguration (SLAAC). Additionally, it specifies a new field in the Prefix Information option of Router Advertisement messages, such that routers can advertise, for each network prefix included in a Router Advertisement message, the desired address generation policy to be used for SLAAC. | ||||||||||||||||
| draft-gont-6man-nd-extension-headers-02.txt | |||||||||||||||||
| Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery | |||||||||||||||||
|
This document analyzes the security implications of using IPv6 Extension Headers with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and provides advice such that the aforementioned security implications are mitigated. | ||||||||||||||||
| draft-gont-6man-oversized-header-chain-01.txt | |||||||||||||||||
| Security and Interoperability Implications of Oversized IPv6 Header Chains | |||||||||||||||||
|
The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that all IPv6 packets are required to contain the entire IPv6 header chain within the first "assumed Path-MTU" bytes of the packet. | ||||||||||||||||
| draft-gont-6man-predictable-fragment-id-02.txt | |||||||||||||||||
| Security Implications of Predictable Fragment Identification Values | |||||||||||||||||
|
IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field which, together with the IPv6 Source Address and the IPv6 Destination Address of the packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together at the receiving host. The only requirement for setting the "Identification" value is that it must be different than that of any other fragmented packet sent recently with the same Source Address and Destination Address. Some implementations simply use a global counter for setting the Fragment Identification field, thus leading to predictable values. This document analyzes the security implications of predictable Identification values, and updates RFC 2460 specifying additional requirements for setting the Fragment Identification, such that the aforementioned security implications are mitigated. | ||||||||||||||||
| draft-gont-6man-stable-privacy-addresses-01.txt | |||||||||||||||||
| 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. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. | ||||||||||||||||
| draft-gont-intarea-obsolete-eid-option-00.txt | |||||||||||||||||
| Obsoleting the Endpoint Identifier (EID) Option | |||||||||||||||||
|
This document formally obsoletes the IPv6 Endpoint Identification (EID) option (hex value 0x8a), thus cleaning up the corresponding IANA registry, and possibly serving as a basis for providing advice about the filtering of packets containing this option. | ||||||||||||||||
| draft-gont-opsec-dhcpv6-shield-00.txt | |||||||||||||||||
| DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers | |||||||||||||||||
|
This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. | ||||||||||||||||
| draft-gont-opsec-ip-options-filtering-04.txt | |||||||||||||||||
| Recommendations on filtering of IPv4 packets containing IPv4 options | |||||||||||||||||
|
This document document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. | ||||||||||||||||
| draft-gont-opsec-ipv6-host-scanning-00.txt | |||||||||||||||||
| Host Scanning 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 host scanning attacks against IPv6 networks, and therefore IPv6 host scanning attacks have long been considered unfeasible. This document analyzes the IPv6 address configuration policies implemented in most popular IPv6 stacks, and identifies a number of patterns in the resulting addresses lead to a tremendous reduction in the host address search space, thus dismantling the myth that IPv6 host scanning attacks are unfeasible. | ||||||||||||||||
| draft-gont-opsec-ipv6-implications-on-ipv4-nets-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-gont-tcpm-tcp-mirrored-endpoints-00.txt | |||||||||||||||||
| Processing of TCP segments with Mirrored End-points | |||||||||||||||||
|
This document describes a problem found in some popular implementations regarding the processing of TCP segments in which the local endpoint is equal to the remote endpoint. Additionally, it formally updates RFC 793 clarifying how this scenario should be handled. | ||||||||||||||||
| draft-gont-tcpm-tcp-seccomp-prec-00.txt | |||||||||||||||||
| Processing of IP Security/Compartment and Precedence Information by TCP | |||||||||||||||||
|
This document discusses the security and interoperability problems that may arise as a result of the processing of IP security/ compartment and precedence information by TCP. Additionally, it formally updates RFC 793 such that these issues are mitigated. | ||||||||||||||||
| draft-gont-teredo-loops-00.txt | |||||||||||||||||
| Mitigating Teredo Rooting Loop Attacks | |||||||||||||||||
|
Recently, a number of routing loop vulnerabilities were discovered in the Teredo mechanism, which typically result in a Denial of Service of the involved systems, possibly also affecting the intervening networks. This document describes a number of security checks that can be performed by Teredo hosts and Teredo servers such that these vulnerabilities are eliminated. | ||||||||||||||||
| draft-gonzalezdedios-pce-reservation-state-01.txt | |||||||||||||||||
| PCEP Extensions for Temporary Reservation of Computed Path Resources and Support for Limited Context State in PCE | |||||||||||||||||
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A limited form of statefulness is useful to improve PCE functionality in situations in which the local TED might not be up to date, or in the case of concurrent requests where most of the LSPs are computed before the end of the set-up of the LSPs, when the TED is updated. The PCC is responsible to setup or not the TE-Path computed by the PCE. By providing an indication that it intends to use the resources on the TE-Path a PCC can help the PCE to get a more accurate dynamic TED view and thus the PCE can avoid suggesting the use of the same resources for subsequent TE LSPs. This document proposes an extension to the PCEP protocol to allow the PCC to indicate to the PCE to block or reserve the resources computed in a path request of a TE LSP for subsequent requests for a certain time and can help to reduce the number of crankbacks. | ||||||||||||||||
| draft-gp-intarea-obsolete-ipv4-options-iana-00.txt | |||||||||||||||||
| Formally Obsoleting some Historic IPv4 Options | |||||||||||||||||
|
A number of IPv4 options have become obsolete in practice, but have never been formally obsoleted. This document obsoletes such IPv4 options, thus cleaning up the corresponding IANA registry, and serving as a basis for providing advice about the filtering of packets containing these options. | ||||||||||||||||
| draft-gredler-idr-ls-distribution-01.txt | |||||||||||||||||
| 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 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). | ||||||||||||||||
| draft-green-bmwg-seceff-bench-meth-01.txt | |||||||||||||||||
| Benchmarking Methodology for Evaluating the Security Effectiveness of Content Aware Devices | |||||||||||||||||
|
This document defines a methodology for evaluating the ability of content-aware network devices to correctly detect and block malicious or administratively disallowed traffic flows. This benchmark addresses the issue of classification accuracy under well defined conditions. It is not concerned with measuring forwarding performance which is covered by other BMWG documents. | ||||||||||||||||
| draft-greevenbosch-hitchhikersguide-sdp-00.txt | |||||||||||||||||
| Hitchhiker's guide to the Session Description Protocol (SDP) | |||||||||||||||||
|
The Session Initiation Protocol (SDP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SDP. This specification serves as a guide to the SDP RFC series. It lists a current snapshot of the specifications under the SDP umbrella, briefly summarises each, and groups them into categories. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. | ||||||||||||||||
| draft-greevenbosch-mmusic-hitchhikersguide-sdp-00.txt | |||||||||||||||||
| Hitchhiker's guide to the Session Description Protocol (SDP) | |||||||||||||||||
|
The Session Initiation Protocol (SDP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SDP. This specification serves as a guide to the SDP RFC series. It lists a current snapshot of the specifications under the SDP umbrella, briefly summarises each, and groups them into categories. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. | ||||||||||||||||
| draft-greevenbosch-mmusic-sdp-3d-format-00.txt | |||||||||||||||||
| Signal 3D format | |||||||||||||||||
|
This document introduces the SDP attribute "3dFormat", which provides format description of stereoscopic 3D video. In addition, the grouping mechanism for SDP is extended to cater for stereoscopic 3D video. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. | ||||||||||||||||
| draft-greevenbosch-mmusic-sdp-parallax-00.txt | |||||||||||||||||
| SDP attribute to signal parallax | |||||||||||||||||
|
This document introduces a "ParallaxInfo" attribute in SDP. This attribute can be used in stereoscopic applications, to signal the depth positioning of 2D media data within the 3D space. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. | ||||||||||||||||
| draft-gross-avtcore-leap-second-00.txt | |||||||||||||||||
| RTP and Leap Seconds | |||||||||||||||||
|
This document discusses issues that arise when RTP sessions span (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. | ||||||||||||||||
| draft-gross-leap-second-01.txt | |||||||||||||||||
| RTP and Leap Seconds | |||||||||||||||||
|
This document discusses issues that arise when RTP sessions span (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. | ||||||||||||||||
| draft-gs-vpn-scaling-01.txt | |||||||||||||||||
| IP VPN Scaling Considerations | |||||||||||||||||
|
This document discusses scaling considerations unique to implementation of Layer 3 (IP) Virtual Private Networks, discusses a few best practices, and identifies gaps in the current tools and techniques which are making it more difficult for operators to cost- effectively scale and manage their L3VPN deployments. | ||||||||||||||||
| draft-gu-opsawg-policies-migration-02.txt | ||||||||||||||
| State Migration | ||||||||||||||
|
In accompany with the migration of a Virtual Machine (VM), state associated with the VM located on the Hypervisors and the network side devices (e.g., Firewalls) need to be updated in order to guarantee that the services executed on the migrated VM will not be disrupted. VM vendors have their own ways to migrate VM's state on Hypervisors, and so this is out the scope of this draft.This draft introduces the background of state migration on network devices using several application scenarios and tries to specify a clear scope for the future standardization work on state migration on network devices. | |||||||||||||
| draft-gulbrandsen-imap-move-01.txt | |||||||||||||||||
| The IMAP Move Extension | |||||||||||||||||
|
The MOVE extension provides a new command, UID MOVE, which moves one or more messages from the selected mailbox to a named mailbox. | ||||||||||||||||
| draft-gundavelli-netext-multiple-apn-pmipv6-01.txt | |||||||||||||||||
| Multiple APN Support for Trusted Wireless LAN Access | |||||||||||||||||
|
This specification defines a mechanism for extending multiple APN/ home-network support for a mobile node. | ||||||||||||||||
| draft-gundavelli-netext-pmipv6-wlan-applicability-03.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-gundavelli-v6ops-community-wifi-svcs-04.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-habault-gallet-homenet-multihoming-sdsa-00.txt | |||||||||||||||||
| Proposal for selecting the default-route according to source address | |||||||||||||||||
|
SDSA approach is to assure that packets, going out the multihomed site, have the correct source address, regarding to the ISP and thus to avoid the ingress filtering problem. In that purpose, SDSA takes into account the source address in the site routing decision for outgoing packets, when default-route is involved. | ||||||||||||||||
| draft-haleplidis-forces-openflow-lib-00.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-hallambaker-decade-ni-params-02.txt | |||||||||||||||||
| The Named Information (ni) URI Scheme: Optional Features | |||||||||||||||||
|
This document specifies optional things that one can do with "ni" URIs and related names. Those include an additional hash algorithm for handling dynamic content, some specific query-strong parameters for ni URIs and a mechanism for embedding ni URIs into QR codes. | ||||||||||||||||
| draft-hallambaker-ocspdigest-00.txt | |||||||||||||||||
| OCSP Digest Extension | |||||||||||||||||
|
The OCSP digest extension creates a strong cryptographic binding between an OCSP token and the certificate it asserts a status value for. Support for the digest identifier extension permits a certificate issuer to employ a high assurance cryptographic digest function such as SHA2 to attest to the authenticity of their certificates in a fashion that is fully downwards compatible with legacy clients that only support SHA1. | ||||||||||||||||
| draft-hallambaker-tlssecuritypolicy-01.txt | |||||||||||||||||
| X.509v3 Extension: OCSP Stapling Required | |||||||||||||||||
|
The purpose of the TLS Security Policy extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS Security Policy extension may be used to mandate support for revocation checking features in the TLS protocol such as OCSP stapling. | ||||||||||||||||
| draft-haluska-gr506-4733-codepoints-00.txt | |||||||||||||||||
| Audio/telephone-event Codes for Operator Services and SIT Tones | |||||||||||||||||
|
This document provides additional information on the use of several specific event codes related to North American Operator Services and Special Information Tones that have been registered in the IANA "audio/telephone-event" registry. | ||||||||||||||||
| draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01.txt | |||||||||||||||||
| Client Link-layer Address Option in DHCPv6 | |||||||||||||||||
|
This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 messages by defining a new DHCPv6 Client Link-layer Address option. | ||||||||||||||||
| draft-hamarsheh-behave-biav2-05.txt | |||||||||||||||||
| Hosts with Any Network Connectivity Using "Bump-in-the-API"(BIA) | |||||||||||||||||
|
This document specifies a mechanism for hosts with any network connectivity (IPv4 only, IPv6 only, or dual IPv4/IPv6 connectivity) to run applications of any capability (IPv4 only, IPv6 only, or dual IPv4/IPv6) without any modification to those applications. It is a generalisation of a previous experimental protocol called "Bump-in-the-API" (BIA) [RFC3338]. New mechanism of BIA allows a changeover between the application layer and the IP communication layers from IPv4 to IPv6 and vice versa or IPv6 to IPv4 and vice versa, without requiring those applications to be converted in addressing capabilities, effectively shielding the application layer from IPv4 or IPv6 connectivity. This is considered by the authors to be one of the essential conditions for the transition to IPv6 in the Internet to be successful. | ||||||||||||||||
| draft-hampel-mptcp-proxies-anchors-00.txt | |||||||||||||||||
| MPTCP Proxies and Anchors | |||||||||||||||||
|
MPTCP proxies and anchors are network-based functions, which support MPTCP connections. The MPTCP proxy provides multipath support for MPTCP-capable hosts on behalf of their MPTCP-unaware peers. This facilitates incremental deployment of MPTCP. The MPTCP anchor permits subflow establishment for MPTCP connections when direct interaction between end hosts fails. This permits tolerance to local IP protocol restrictions and it provides robustness in case of break- before-make mobility events. MPTCP proxies and anchors are especially suited for wireless access environments. | ||||||||||||||||
| draft-hansen-nonkeywords-non2119-02.txt | |||||||||||||||||
| Non-Normative Synonyms in RFCs | |||||||||||||||||
|
Specifications in RFCs contain normative keywords, as defined in RFC 2119, to signify requirements, permission or prohibitions. These include MUST, SHOULD and MAY, which are commonly recorded in all CAPITALS (but need not be). The words are sometimes also intended with non-normative meaning; this different usage can be confusing. Happily there are adequate alternatives for non-normative meanings. For such situations, this document provides some alternatives to the normative vocabulary of RFC 2119. | ||||||||||||||||
| draft-hao-pwe3-iccp-extension-for-msp-02.txt | |||||||||||||||||
| ICCP extension for the MSP application | |||||||||||||||||
|
This document specifies some extensions on Inter-Chassis Communication Protocol(ICCP) to support inter-chassis linear multiplex section protection(MSP) that is described in G.841. Linear multiplex section protection(MSP) is used to protect Synchronous Digital Hierarchy (SDH) links which could be used as attachment circuits to dual-home to two or more PEs. In this case, ICCP is introduced to support the configuration and state synchronization between two chassises. | ||||||||||||||||
| draft-hapner-hybi-messagebroker-subprotocol-01.txt | |||||||||||||||||
| The MessageBroker WebSocket Subprotocol | |||||||||||||||||
|
The WebSocket protocol [I-D.ietf-hybi-thewebsocketprotocol] provides a subprotocol extension facility. The MessageBroker WebSocket Subprotocol (MBWS) is a WebSocket Subprotocol used by messaging clients to send messages to, and receive messages from an internet message broker (herein called a message broker). A message broker is a messaging intermediary that queues messages sent by its clients for asynchronous delivery to its clients. Messages are addressed to message-broker-specific address names. Clients send messages to addresses and consume messages from addresses. Clients do not send messages directly to other clients. Message brokers provide a range of functionality that is outside the scope of MBWS. Typically an internet message broker provides a REST API for working with this functionality; such as configuring client credentials; setting client access controls; configuring address routing; etc. MBWS limits its scope to the definition of a WebSocket subprotocol that provides a full duplex, reliable message transport protocol between message brokers and their clients; and, between message brokers. Since reliable message transport is often independent of a broker's particular features, MBWS can be used as the message transport protocol for a wide range of message brokers. The MBWS subprotocol defines a binary message frame and a text message frame. Both types of frame carry the same protocol; however, the protocol bindings differ slightly. The binary frame is a WebSocket binary message that contains an MBWS binary header followed by a binary message body. The text frame is a WebSocket UTF-8 text message that contains an MBWS text header followed by a text message body. | ||||||||||||||||
| draft-harada-xmpp-srv-record-query-00.txt | |||||||||||||||||
| SRV record query extension for XMPP | |||||||||||||||||
|
According to RFC 6120, XMPP clients should use SRV records within the connection establishment process to servers. There are two purposes for using SRV records. The one is to advertise the FQDN of at least one server to clients to establish an initial TCP connection. The other purpose is to advertise at least two or more FQDN with priority and weight information to clients to accomplish load balancing, a redundant server environment and so on. However, most standard resolver libraries of recent client OSs don't support SRV record resolution. Furthermore, many DNS hosting services also don't support SRV records. This document proposes a solution that enables a server and client to achieve load balancing and a redundant server environment in case SRV records cannot be used. Moreover, the proposed IQ-result message can include minimum wait time to reconnect, allowing clients to reconnect after the most suitable wait time avoiding congestion. | ||||||||||||||||
| draft-hardie-rm-rr-00.txt | |||||||||||||||||
| The Reachability Method (RM) DNS Resource Record | |||||||||||||||||
|
This draft proposes a DNS resource record for providing adjunct reachability methods for network hosts or resources which are only accessible within limited reachability domains. | ||||||||||||||||
| draft-harding-as2-restart-03.txt | |||||||||||||||||
| 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 | ||||||||||||||||
| draft-hardjono-oauth-dynreg-03.txt | |||||||||||||||||
| OAuth Dynamic Client Registration Protocol | |||||||||||||||||
|
This specification proposes an OAuth Dynamic Client Registration protocol. | ||||||||||||||||
| draft-hardjono-oauth-umacore-04.txt | |||||||||||||||||
| User-Managed Access (UMA) Core Protocol | |||||||||||||||||
|
This specification defines the User-Managed Access (UMA) core protocol. This protocol provides a method for users to control access to their protected resources, residing on any number of host sites, through an authorization manager that governs access decisions based on user policy. | ||||||||||||||||
| draft-haresh-sushrut-mib-classification-01.txt | |||||||||||||||||
| SNMPD to use cache and shared database based on MIB Classification | |||||||||||||||||
|
This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device. | ||||||||||||||||
| draft-harkins-rochambeau-00.txt | |||||||||||||||||
| An M-party,N-state Game of Rochambeau | |||||||||||||||||
|
A protocol for the fair selection and random distribution of a single winner in a game with an arbitrary number of players is described. | ||||||||||||||||
| draft-harkins-tls-pwd-02.txt | |||||||||||||||||
| Secure Password Ciphersuites for Transport Layer Security (TLS) | |||||||||||||||||
|
This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The ciphersuites are all based on an authentication and key exchange protocol that is resistant to off-line dictionary attack. | ||||||||||||||||
| draft-hartke-core-coap-xmpp-00.txt | |||||||||||||||||
| A CoAP REST API for XMPP Publish-Subscribe | |||||||||||||||||
|
The REST API defined in this document enables Constrained Application Protocol (CoAP) clients to interact with Extensible Messaging Protocol (XMPP) Publish-Subscribe services by delegating the task of creating, retrieving, updating and deleting pubsub items and nodes to a CoAP/XMPP proxy. | ||||||||||||||||
| draft-hartke-core-codtls-01.txt | |||||||||||||||||
| Datagram Transport Layer Security in Constrained Environments | |||||||||||||||||
|
We consider some obstacles in implementing Datagram Transport Layer Security (DTLS) in constrained environments, and present some ideas for a constrained version of DTLS that is friendly to constrained nodes and networks. | ||||||||||||||||
| draft-hartman-emu-mutual-crypto-bind-00.txt | |||||||||||||||||
| EAP Mutual Cryptographic Binding | |||||||||||||||||
|
As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. [RFC 3748] is a facility that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in- the-middle attacks and recommends mutual cryptographic binding, a new form of cryptographic binding that protects both peer and server. | ||||||||||||||||
| draft-hartman-karp-mrkmp-04.txt | |||||||||||||||||
| Multicast Router Key Management Protocol (MaRK) | |||||||||||||||||
|
Several routing protocols engage in one-to-many communication. In order to authenticate these communications using symmetric cryptography, a group key needs to be established. This specification defines a group protocol for establishing and managing such keys. | ||||||||||||||||
| draft-hartmann-default-port-for-irc-via-tls-ssl-07.txt | |||||||||||||||||
| Default Port for IRC via TLS/SSL | |||||||||||||||||
|
This document describes the commonly accepted practice of listening on TCP port 6697 for incoming IRC connections encrypted via TLS/SSL. | ||||||||||||||||
| draft-hayatnagarkar-dnsext-validator-api-09.txt | |||||||||||||||||
| DNSSEC Validator API | |||||||||||||||||
|
The DNS Security Extensions (DNSSEC) provide origin authentication and integrity of DNS data. However, the current resolver Application Programming Interface (API) does not specify how a validating stub resolver should communicate results of DNSSEC processing back to the application. This document describes an API between applications and a validating stub resolver that allows applications to control the DNSSEC validation process and obtain results of DNSSEC processing. | ||||||||||||||||
| draft-hazeyama-widecamp-ipv6-only-experience-01.txt | |||||||||||||||||
| Experiences from IPv6-Only Networks with Transition Technologies in the WIDE Camp Spring 2012 | |||||||||||||||||
|
This document reports and discusses issues on IPv6 only networks and IPv4/IPv6 transition technologies through our experiences on the 2nd experiment on the WIDE camp. The second experiment was held from March 4th to March 8th, 2012. We tried to live in commercial IPv6 networks with four kinds of IPv4/IPv6 transition technologies, DNS64/ NAT64, 4RD, 464XLAT and SA46T. In this -01.txt aims to report results of the 2nd experiment and to share issues / problems on the IPv4 / IPv6 transition that we met. | ||||||||||||||||
| draft-he-cdni-cap-info-advertising-01.txt | |||||||||||||||||
| Capability Information Advertising for CDN Interconnection | |||||||||||||||||
|
This document describes protocol for capability information advertising which is used to communicate capability and status information among interconnected Content Delivery Networks (CDNs). | ||||||||||||||||
| draft-he-cdni-routing-request-redirection-01.txt | |||||||||||||||||
| Routing Request Redirection for CDN Interconnection | |||||||||||||||||
|
The Request Routing Interface comprises the asynchronous advertisement of footprint and capabilities by a dCDN that allows a uCDN to decide whether to redirect particular user requests to that dCDN; and the synchronous operation of actually redirecting a user request. This document describes protocol for the part of user requests redirection. | ||||||||||||||||
| draft-helvoort-mpls-tp-ring-protection-switching-02.txt | |||||||||||||||||
| MPLS-TP Ring Protection Switching (MRPS) | |||||||||||||||||
|
This document describes a mechanism to address the requirements for protection of the Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) in a ring topology. The mechanism defined herein is designed to support point-to-point as well as point-to-multipoint LSPs. The MPLS-TP section layer OAM is used to monitor the connectivity between each two adjacent nodes using the mechanisms defined in the [RFC6371]. The Automatic Protection Switching (APS) protocol is used for coordination of protection switching actions between the ring nodes. | ||||||||||||||||
| draft-henderson-hip-vpls-04.txt | |||||||||||||||||
| HIP-based Virtual Private LAN Service (HIPLS) | |||||||||||||||||
|
The Host Identity Protocol (HIP) and architecture adds a cryptographic name space to name Internet hosts. This draft describes a use case of the HIP architecture, which is to provide a HIP-enabled virtual private LAN service (VPLS) over an untrusted network. In this case, HIP is used to secure tunnels between the provider edge (PE) equipment. | ||||||||||||||||
| draft-hennessy-bsp-suiteb-ciphersuites-00.txt | |||||||||||||||||
| Suite B Ciphersuites for the Bundle Security Protocol | |||||||||||||||||
|
This document proposes eight ciphersuites for the Bundle Security Protocol (BSP), similar to the four suites specified in RFC 6257. The eight new ciphersuites provide compatibility with the United States National Security Agency's Suite B specifications. | ||||||||||||||||
| draft-hennessy-bsp-suiteb-profile-00.txt | |||||||||||||||||
| Suite B Profile for the Bundle Security Protocol | |||||||||||||||||
|
The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in the Bundle Security Protocol (BSP) Since many of the Suite B algorithms enjoy uses in other environments as well, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant details repeated to aid developers that choose to support Suite B. | ||||||||||||||||
| draft-herberg-manet-nhdp-sec-threats-01.txt | |||||||||||||||||
| Security Threats for NHDP | |||||||||||||||||
|
This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. | ||||||||||||||||
| draft-herzog-withmac-keywrap-01.txt | |||||||||||||||||
| The With-MAC key-wrapping algorithm for Cryptographic Message Syntax | |||||||||||||||||
|
This document describes a new key-wrapping algorithm to be used in the EnvelopedData, AuthenticatedData and AuthEnvelopedData structures of the Cryptographic Message Syntax. Because these structures do not provide data-origin authentication, a recipient cannot cryptographically verify that the plaintext received was the plaintext encapsulated by the message's original sender. The With- MAC key-wrapping algorithm allows an EncryptedKey value to hold both a wrapped symmetric key and a MAC value on the data to be authenticated. When used in EnvelopedData, AuthenticatedData and AuthEnvelopedData structures, therefore, these structures can achieve data-origin authentication (in some circumstances) using only symmetric-key algorithms. This is useful in cases where the structures must be generated by entities without certified digital- signature keys. | ||||||||||||||||
| draft-hilliard-ix-bgp-route-server-operations-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-hoehrmann-cp-collation-01.txt | |||||||||||||||||
| The i;codepoint collation | |||||||||||||||||
|
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. | ||||||||||||||||
| draft-hoehrmann-nomap-00.txt | |||||||||||||||||
| The "nomap" Network Identifier Suffix | |||||||||||||||||
|
This memo defines a method for network operators to indicate that information about their network is broadcast only to allow legitimate participants in the network to connect or re-connect to them, and that other uses of such information are to be avoided. | ||||||||||||||||
| draft-hoeneisen-rfc5333bis-01.txt | |||||||||||||||||
| IANA Registration of Enumservices for Internet Calendaring | |||||||||||||||||
|
This document registers and obsoletes Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for iMIP (iCalendar Message-Based Interoperability Protocol), CalDAV (Calendaring Extensions to WebDAV), and iSchedule (Internet Calendar Scheduling Protocol). | ||||||||||||||||
| draft-hoffman-dane-smime-03.txt | |||||||||||||||||
| Using Secure DNS to Associate Certificates with Domain Names For S/MIME | |||||||||||||||||
|
S/MIME uses certificates for authenticating and encrypting messages. Users want their mail user agents to securely associate a certificate with the sender of an encrypted and/or signed message. DNSSEC provides a mechanism for a zone operator to sign DNS information directly. This way, bindings of certificates to users within a domain are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name. IMPORTANT NOTE: This draft is intentionally sketchy. It is meant as a possible starting point for the DANE WG if it wants to consider making a protocol similar to TLSA, as described in draft-ietf-dane-protocol, but that applies to S/MIME. The WG may or may not want to adopt such work, or if it does, may want to use a very different scheme from the one described here. | ||||||||||||||||
| draft-hoffman-rfcformat-canon-others-01.txt | |||||||||||||||||
| Proposal for Canonical and Other Formats for RFCs | |||||||||||||||||
|
This document proposes a modernized text-based canonical format for RFCs that explicitly allows external art as a normative part of the RFC. If the RFC Editor chooses this format, they will also publish non-canonical versions of RFCs in order to accomodate the largest target audience of readers. Having a simple, stable canonical format and a varying number of non-canonical formats that can change over time allows the RFC Editor to add useful formats, particularly in HTML, that can keep up with the needs of all RFC readers. | ||||||||||||||||
| draft-hohendorf-secure-sctp-13.txt | |||||||||||||||||
| Secure SCTP | |||||||||||||||||
|
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP. | ||||||||||||||||
| draft-hollenbeck-dnrd-ap-query-01.txt | |||||||||||||||||
| Domain Name Registration Data Access Protocol Query Format | |||||||||||||||||
|
This document describes a RESTful query format proposal for the Domain Name Registration Data Access Protocol. | ||||||||||||||||
| draft-hotz-kx509-04.txt | |||||||||||||||||
| KX509 Kerberized Certificate Issuance Protocol | |||||||||||||||||
|
This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists then the overhead of using kx509 may be much less. While not (previously) standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. | ||||||||||||||||
| draft-howard-homenet-routing-comparison-00.txt | |||||||||||||||||
| Evaluation of Proposed Homenet Routing Solutions | |||||||||||||||||
|
This document evaluates the various proposals for routing in an unmanaged home network. | ||||||||||||||||
| draft-howard-homenet-routing-requirements-00.txt | |||||||||||||||||
| Homenet Routing Requirements | |||||||||||||||||
|
This document describes the requirements for routing in an unmanaged home network. | ||||||||||||||||
| draft-howlett-abfab-trust-router-ps-02.txt | |||||||||||||||||
| Trust Router Problem Statement | |||||||||||||||||
|
This document is a problem statement for a Trust Router Protocol. A Trust Router Protocol is needed to support large, multihop ABFAB federations, without the need for credentials to be configured for every pair of Identity Providers and Relying Parties. | ||||||||||||||||
| draft-hryckelynck-writing-rfcs-04.txt | |||||||||||||||||
| Mail Accepted by Previous Sending | |||||||||||||||||
|
Mail Accepted by Previous Sending defines a mechanism by which incoming unsollicited mails may be rejected or penalized by a MTA if their sender address domains has never been a destination for the outgoing mails treated by this MTA. | ||||||||||||||||
| draft-hsingh-6man-enhanced-dad-04.txt | |||||||||||||||||
| Enhanced Duplicate Address Detection | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-hu-trill-pseudonode-nickname-02.txt | |||||||||||||||||
| RBridge: Pseudo-Nickname | |||||||||||||||||
|
At the edg of TRILL campus, some RBridges provide end-station services to their attached end stations, these RBridges are called edge RBridges. To avoid potential frame duplication or loops in TRILL campus, only one edge RBridge is permitted to provide end- station services in a VLAN x at all times for its attached end stations. However, in some application scenarios, for example in Link Aggregation Group (LAG), more than one edge RBridge is required to provide end-station services to an end stations even in a VLAN, which causes the flip-flopping of the egress RBridge nickname for such an end node in remote RBridges' forwarding tables if nothing to do. In this document, the concept of Virtual RBridge, along with its pseudo-nickname, is introduced to fix the above problem. | ||||||||||||||||
| draft-hu-trill-rbridge-esadi-04.txt | |||||||||||||||||
| TRILL: The ESADI Protocol | |||||||||||||||||
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports the multi-pathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called RBridges (Routing Bridges) or TRILL Switches. The ESADI (End System Address Distribution Information) protocol is a VLAN (Virtual Local Area Network) scoped way that TRILL switches can communicate end station addresses to each other. An RBridge announcing VLAN-x connectivity (normally a VLAN-x appointed forwarder) and running the TRILL ESADI protocol can receive remote address information and/or transmit local address information for VLAN-x to other such RBridges. This document updates RFC 6325, specifically the documentation of the ESADI protocol. | ||||||||||||||||
| draft-hu-trill-rbridge-vrrp-02.txt | |||||||||||||||||
| Extending the Virtual Router Redundancy Protocol for TRILL campus | |||||||||||||||||
|
TRILL can be implemented in data center networks, which requires high reliability and stability. Whenever the egress RBridges or links break down, the TRILL rerouting time depends on the IS-IS topology convergence time, which may do not meet data center service requirements in terms of resiliency. VRRP provides a redundancy mechanism to avoid single point of failure and fast switching over. This draft proposes to extend VRRP protocol to TRILL in data center networks. | ||||||||||||||||
| draft-hu-trill-traffic-engineering-00.txt | |||||||||||||||||
| TRILL: Traffic Engineering | |||||||||||||||||
|
This document specifies the control plane procedures to support Traffic Engineering (TE) in the TRILL protocol. Traffic Engineering permits management configuration of the path followed by certain unicast frames in a TRILL campus. | ||||||||||||||||
| draft-huang-rtcweb-monitoring-00.txt | |||||||||||||||||
| Web Real-Time Communication (RTCWEB): Monitoring Usage | |||||||||||||||||
|
This document describes the monitoring aspect usage in RTCWeb. It also gives some guidelines for which RTCP XR metrics and extentions need to be supported. | ||||||||||||||||
| draft-huang-xrblock-rtcp-xr-decodability-03.txt | |||||||||||||||||
| RTCP XR Report Block for TS Decodability Statistics Metric reporting | |||||||||||||||||
|
Transport Stream is a standard container format used in the transmission and storage of multimedia data. This document defines an RTCP XR Report Block that allows the reporting of decodability statistics metrics related to transmissions in Transport Stream format. This XR Report Block includes 8 metrics from ETSI TR 101 290, which are most important and most universal metrics from priorities 1 and 2. The metrics from priority 3 are defined as application dependent monitoring, and the unadopted metrics are never or seldom happending during the content transmission. So this kind of metrics are omitted by this draft. | ||||||||||||||||
| draft-hui-multimob-fast-handover-04.txt | |||||||||||||||||
| Fast Handover for Multicast in Proxy Mobile IPv6 | |||||||||||||||||
|
This document specifies the predictive fast handover mechanism to solve the problem of handover latency and packet loss in Proxy Mobile IPv6 Multicast. Necessary extensions are specified for Handover Initiate (HI) and Handover Acknowledgement (HAck) messages to support multicast handover procedure. | ||||||||||||||||
| draft-hunt-scim-targeting-00.txt | |||||||||||||||||
| SCIM Targeted Resource Extension | |||||||||||||||||
|
The core SCIM 1.0 specification is intended to provide updates to a single cloud-based application. This extension specifies an extended API definition which allows a single SCIM endpoint to support updates to multiple cloud-based applications. These extensions enable network relationships such as proxy updates, and hub-to-hub-to-spoke relationships in addition to the hub-spoke relationship defined in the core SCIM 1.0 specification. | ||||||||||||||||
| draft-hussain-ccamp-super-channel-label-03.txt | |||||||||||||||||
| Generalized Label for Super-Channel Assignment on Flexible Grid | |||||||||||||||||
|
To enable scaling of existing transport systems to ultra high data rates of 1 Tbps and beyond, next generation systems providing super- channel switching capability are currently being developed. To allow efficient allocation of optical spectral bandwidth for such high bit rate systems, International Telecommunication Union Telecommunication Standardization Sector (ITU-T) is extending the G.694.1 grid standard (termed "Fixed-Grid") to include flexible grid (termed "Flex-Grid") support (draft revised ITU-T G.694.1, revision 1.4, Oct 2011). This necessitates definition of new label format for the Flex-Grid. This document defines a super-channel label as a Super-Channel Identifier and an associated list of 12.5 GHz slices representing the optical spectrum of the super-channel. The label information can be encoded using a fixed length or variable length format. This label format can be used in GMPLS signaling and routing protocol to establish super-channel based optical label switched paths (LSPs). | ||||||||||||||||
| draft-hussain-ccamp-super-channel-param-ospfte-00.txt | |||||||||||||||||
| Super-Channel Optical Parameters GMPLS Routing Extensions | |||||||||||||||||
|
This document builds on [6][7] and defines GMPLS routing extensions to allow added CSPF constraints for efficient super-channel spectrum assignment on flexible grid networks. | ||||||||||||||||
| draft-hussain-ccamp-super-channel-param-sig-00.txt | |||||||||||||||||
| Super-Channel Optical Parameters GMPLS Signaling Extensions | |||||||||||||||||
|
This document builds on [6][7] and defines GMPLS signaling extensions to carry super-channel optical parameters for efficient spectrum assignment on flexible grid networks. | ||||||||||||||||
| draft-iab-extension-recs-11.txt | |||||||||||||||||
| Design Considerations for Protocol Extensions | |||||||||||||||||
|
This document discusses issues related to the extensibility of Internet protocols, with a focus on architectural design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. | ||||||||||||||||
| draft-iab-identifier-comparison-02.txt | |||||||||||||||||
| Issues in Identifier Comparison for Security Purposes | |||||||||||||||||
|
Identifiers such as hostnames, URIs, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier supplied via some protocol is often compared against some policy to make security decisions such as whether the principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. | ||||||||||||||||
| draft-iab-privacy-considerations-02.txt | |||||||||||||||||
| Privacy Considerations for Internet Protocols | |||||||||||||||||
|
This document offers guidance for developing privacy considerations for IETF documents and aims to make protocol designers aware of privacy-related design choices. Discussion of this document is taking place on the IETF Privacy Discussion mailing list (see https://www.ietf.org/mailman/listinfo/ietf-privacy). | ||||||||||||||||
| draft-iab-privacy-terminology-01.txt | |||||||||||||||||
| Privacy Terminology and Concepts | |||||||||||||||||
|
Privacy is a concept that has been debated and argued throughout the last few millennia. Its most striking feature is the difficulty that disparate parties encounter when they attempt to precisely define it. In order to discuss privacy in a meaningful way, a tightly defined context is necessary. The specific context of privacy used within this document is that of personal data in Internet protocols. Personal data is any information relating to a data subject, where a data subject is an identified natural person or a natural person who can be identified, directly or indirectly. A lot of work within the IETF involves defining protocols that can potentially transport (either explicitly or implicitly) personal data. This document aims to establish a consistent lexicon around privacy for IETF contributors to use when discussing privacy considerations within their work. Note: This document is discussed at https://www.ietf.org/mailman/listinfo/ietf-privacy | ||||||||||||||||
| draft-iab-rfc-editor-model-v2-05.txt | |||||||||||||||||
| RFC Editor Model (Version 2) | |||||||||||||||||
|
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: The RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and the RSOC. This document reflects the experience gained with RFC Editor Model version 1, documented in [RFC5620] and obsoletes that document. | ||||||||||||||||
| draft-iab-rfc3356bis-01.txt | |||||||||||||||||
| Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines | |||||||||||||||||
|
This document provides guidance to aid in the understanding of collaboration on standards development between the International Telecommunication Union -- Telecommunication Standardization Sector (ITU-T) and the Internet Society (ISOC) -- Internet Engineering Task Force (IETF). It is an update of and obsoletes RFC 3356. The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T Supplement 3 to the ITU-T A-Series Recommendations. Note: This was approved by ITU-T TSAG on xx July 2012 as a Supplement to the ITU-T A-Series of Recommendations (will be numbered as A-Series Supplement 3). | ||||||||||||||||
| draft-ibc-sipcore-sip-websocket-02.txt | |||||||||||||||||
| The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) | |||||||||||||||||
|
The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities and enables usage of the SIP protocol in new scenarios. | ||||||||||||||||
| draft-ietf-6lowpan-btle-07.txt | |||||||||||||||||
| Transmission of IPv6 Packets over Bluetooth Low Energy | |||||||||||||||||
|
Bluetooth Low Energy is a low power air interface technology defined by the Bluetooth Special Interest Group (BT SIG). The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets and many other devices. The low power version of Bluetooth is a new specification and enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low power variant of Bluetooth is commonly specified in revision 4.0 of the Bluetooth specifications and commonly refered to as Bluetooth 4.0. This document describes how IPv6 is transported over Bluetooth Low Energy using 6LoWPAN techniques. | ||||||||||||||||
| draft-ietf-6lowpan-nd-18.txt | |||||||||||||||||
| Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN) | |||||||||||||||||
|
The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless Personal Area Networks such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non-transitive wireless links. The traditional IPv6 link concept and heavy use of multicast make the protocol inefficient and sometimes impractical in a low power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, addressing mechanisms and duplicate address detection for 6LoWPAN and similar networks. The document, thus updates RFC 4944 to specify the use of the optimizations defined here. | ||||||||||||||||
| draft-ietf-6lowpan-routing-requirements-10.txt | |||||||||||||||||
| Problem Statement and Requirements for 6LoWPAN Routing | |||||||||||||||||
|
6LoWPANs are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification define how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported. This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPAN networks, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions, but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing, which can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPAN, such as the IETF ROLL WG. | ||||||||||||||||
| draft-ietf-6man-6lobac-01.txt | |||||||||||||||||
| Transmission of IPv6 over MS/TP Networks | |||||||||||||||||
|
MS/TP (Master-Slave/Token-Passing) is a contention-free access method for the RS-485 physical layer that is used extensively in building automation networks. This document describes the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. | ||||||||||||||||
| draft-ietf-6man-addr-select-opt-03.txt | |||||||||||||||||
| Distributing Address Selection Policy using DHCPv6 | |||||||||||||||||
|
RFC 3484 defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 3484 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 policy table, and thus control the address selection behavior of nodes in their site. | ||||||||||||||||
| draft-ietf-6man-dad-proxy-02.txt | |||||||||||||||||
| Duplicate Address Detection Proxy | |||||||||||||||||
|
The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. | ||||||||||||||||
| draft-ietf-6man-enhanced-dad-00.txt | |||||||||||||||||
| Enhanced Duplicate Address Detection | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ietf-6man-impatient-nud-01.txt | |||||||||||||||||
| Neighbor Unreachability Detection is too impatient | |||||||||||||||||
|
IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternatives, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allows an implementation to choose different timeout behavior based on whether or not there are alternatives. | ||||||||||||||||
| draft-ietf-6man-ipv6-atomic-fragments-00.txt | |||||||||||||||||
| Processing of IPv6 "atomic" fragments | |||||||||||||||||
|
The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces. Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by some implementations as "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that fragmentation-based attack vectors against traffic employing "atomic fragments" are completely eliminated. | ||||||||||||||||
| draft-ietf-6man-lineid-04.txt | |||||||||||||||||
| The Line Identification Destination Option | |||||||||||||||||
|
In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the Edge Router. | ||||||||||||||||
| draft-ietf-6man-rfc3484bis-04.txt | |||||||||||||||||
| Default Address Selection for Internet Protocol version 6 (IPv6) | |||||||||||||||||
|
This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. This document obsoletes RFC 3484. | ||||||||||||||||
| draft-ietf-6man-stable-privacy-addresses-00.txt | |||||||||||||||||
| 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. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. | ||||||||||||||||
| draft-ietf-6man-udpchecksums-02.txt | |||||||||||||||||
| UDP Checksums for Tunneled Packets | |||||||||||||||||
|
This document provides an update of RFC 2460[RFC2460] in order to improve the performance of IPv6 in an increasingly important use case, the use of tunneling to carry new transport protocols. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for suitable tunneling protocol where header information is protected on the "inner" packet being carried. This relaxation removes the overhead associated with the computation of UDP checksums on tunneled IPv6 packets and thereby improves the efficiency of the traversal of firewalls and other network middleware by such new protocols. We describe how the IPv6 UDP checksum requirement can be relaxed in the situation where the encapsulated packet itself contains a checksum, the limitations and risks of this approach, and provides restrictions on the use of this relaxation to mitigate these risks. | ||||||||||||||||
| draft-ietf-6man-udpzero-05.txt | |||||||||||||||||
| IPv6 UDP Checksum Considerations | |||||||||||||||||
|
This document examines the role of the UDP transport checksum when used with IPv6, as defined in RFC2460. It presents a summary of the trade-offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field as an indication that no checksum is present. This method is compared with some other possibilities. The document also describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations. It concludes that UDP with a zero checksum in IPv6 can safely be used for this purpose, provided that this usage is governed by a set of constraints. | ||||||||||||||||
| draft-ietf-6man-uri-zoneid-00.txt | |||||||||||||||||
| Representing IPv6 Zone Identifiers in Uniform Resource Identifiers | |||||||||||||||||
|
This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a Uniform Resource Identifier that includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. | ||||||||||||||||
| draft-ietf-6renum-enterprise-00.txt | |||||||||||||||||
| IPv6 Enterprise Network Renumbering Scenarios and Guidelines | |||||||||||||||||
|
This document analyzes enterprise renumbering events and describes the best current practice among the existing renumbering mechanisms. According to the different stages of renumbering events, considerations and best current practices are described in three categories: during network design, for preparation of renumbering, and during a renumbering operation. A gap inventory is listed at the end of this document. | ||||||||||||||||
| draft-ietf-6renum-gap-analysis-01.txt | |||||||||||||||||
| IPv6 Site Renumbering Gap Analysis | |||||||||||||||||
|
This document briefly introduces the existing mechanisms could be utilized by IPv6 site renumbering and envisions the effort could be done. This document tries to cover the most explicit issues and requirements of IPv6 renumbering. Through the gap analysis, the document provides a basis for future work to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is presented following a renumbering event procedure clue. | ||||||||||||||||
| draft-ietf-abfab-aaa-saml-03.txt | |||||||||||||||||
| A RADIUS Attribute,Binding and Profiles for SAML | |||||||||||||||||
|
This document specifies a RADIUS attribute, a binding and two profiles for the Security Assertion Mark-up Language (SAML). The attribute provides RADIUS encapsulation of SAML protocol messages, while the binding describes the transport of this attribute, and the SAML protocol messages within, using RADIUS. The profiles describe the application of this binding for Abfab authentication and assertion query/request. The SAML RADIUS attribute and binding are defined generically to permit application in other scenarios, such as network access. | ||||||||||||||||
| draft-ietf-abfab-arch-02.txt | |||||||||||||||||
| Application Bridging for Federated Access Beyond Web (ABFAB) Architecture | |||||||||||||||||
|
Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use-cases: network and web-based access. However, the solutions to these use-cases that have been proposed and deployed tend to have few common building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) and the Diameter protocol, the Generic Security Service (GSS), the GS2 family, the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. | ||||||||||||||||
| draft-ietf-abfab-gss-eap-07.txt | |||||||||||||||||
| A GSS-API Mechanism for the Extensible Authentication Protocol | |||||||||||||||||
|
This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. | ||||||||||||||||
| draft-ietf-abfab-gss-eap-naming-02.txt | |||||||||||||||||
| Name Attributes for the GSS-API EAP mechanism | |||||||||||||||||
|
The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. | ||||||||||||||||
| draft-ietf-abfab-usecases-02.txt | |||||||||||||||||
| Application Bridging for Federated Access Beyond web (ABFAB) Use Cases | |||||||||||||||||
|
Federated authentication has so far been typically associated with Web-based services, but there is growing interest in the application of federated authentication for non-Web services. The goal of this document is to document a selection of the wide variety of contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. | ||||||||||||||||
| draft-ietf-adslmib-gbond-atm-mib-06.txt | |||||||||||||||||
| ATM-Based xDSL Bonded Interfaces MIB | |||||||||||||||||
|
This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based networks. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.1. | ||||||||||||||||
| draft-ietf-adslmib-gbond-eth-mib-06.txt | |||||||||||||||||
| Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB | |||||||||||||||||
|
This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.2. | ||||||||||||||||
| draft-ietf-adslmib-gbond-mib-10.txt | |||||||||||||||||
| xDSL multi-pair bonding (G.Bond) MIB | |||||||||||||||||
|
This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in G9981-MIB, G9982-MIB and G9983-MIB respectively. | ||||||||||||||||
| draft-ietf-adslmib-gbond-tdim-mib-08.txt | |||||||||||||||||
| xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB | |||||||||||||||||
|
This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), defined in ITU-T recommendation G.998.3. | ||||||||||||||||
| draft-ietf-alto-deployments-04.txt | |||||||||||||||||
| ALTO Deployment Considerations | |||||||||||||||||
|
Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to these applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. The protocol is under specification in the ALTO working group. This memo discusses deployment related issues of ALTO for peer-to-peer and CDNs, some preliminary security considerations, and also initial guidance for application designers using ALTO. | ||||||||||||||||
| draft-ietf-alto-protocol-11.txt | |||||||||||||||||
| ALTO Protocol | |||||||||||||||||
|
Networking applications today already have access to a great amount of Inter-Provider network topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to be downloaded by clients. What is missing is knowledge of the underlying network topology from the ISP or Content Provider (henceforth referred as Provider) point of view. In other words, what a Provider prefers in terms of traffic optimization -- and a way to distribute it. The ALTO Service provides network information (e.g., basic network location structure, 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 simplified, yet enough information of a network for applications to effectively utilize. Additional services are built on top the maps. This document describes a protocol implementing the ALTO Service. Although the ALTO service would primarily be provided by the network (i.e., the ISP), content providers and third parties could also operate this service. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer (P2P) and content delivery networks. | ||||||||||||||||
| draft-ietf-alto-reqs-14.txt | |||||||||||||||||
| Application-Layer Traffic Optimization (ALTO) Requirements | |||||||||||||||||
|
Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates capable of providing a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance (or Quality of Experience) in the application while reducing resource consumption in the underlying network infrastructure. This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. | ||||||||||||||||
| draft-ietf-alto-server-discovery-03.txt | |||||||||||||||||
| ALTO Server Discovery | |||||||||||||||||
|
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates that are able to provide a desired resource. Entities seeking guidance need to discover and possibly select an ALTO server to ask. This is called ALTO server discovery. This memo describes an ALTO server discovery mechanism based on several alternative mechanisms that are applicable in a diverse set of ALTO deployment scenarios. | ||||||||||||||||
| draft-ietf-ancp-mc-extensions-07.txt | |||||||||||||||||
| Multicast Control Extensions for ANCP | |||||||||||||||||
|
This document specifies the extensions to the Access Node Control Protocol required for support of the multicast use cases defined in the Access Node Control Protocol framework document and one additional use case described in this document. These use cases are organized into the following ANCP capabilities: o NAS-initiated multicast replication; o conditional access with white and black lists; o conditional access with grey lists; o bandwidth delegation; o committed bandwidth reporting. These capabilities may be combined according to the rules given in this specification. | ||||||||||||||||
| draft-ietf-ancp-mib-an-09.txt | |||||||||||||||||
| Access Node Control Protocol (ANCP) MIB module for Access Nodes | |||||||||||||||||
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). | ||||||||||||||||
| draft-ietf-ancp-pon-02.txt | |||||||||||||||||
| Applicability of Access Node Control Mechanism to PON based Broadband Networks | |||||||||||||||||
|
The purpose of this document is to provide applicability of the Access Node Control Mechanism, as described in [RFC5851], to PON based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements) is described in a multi-service reference architecture in order to perform QoS- related, service-related and Subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses a direct device-to- device communication and stays on net. This allows for performing access link related operations within those network elements to meet performance objectives. | ||||||||||||||||
| draft-ietf-appsawg-about-uri-scheme-04.txt | |||||||||||||||||
| The "about" URI Scheme | |||||||||||||||||
|
This document specifies the "about" URI scheme, which is widely used by web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. | ||||||||||||||||
| draft-ietf-appsawg-greylisting-09.txt | |||||||||||||||||
| Email Greylisting: An Applicability Statement for SMTP | |||||||||||||||||
|
This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. | ||||||||||||||||
| draft-ietf-appsawg-http-forwarded-02.txt | |||||||||||||||||
| Forwarded HTTP Extension | |||||||||||||||||
|
This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, e.g., the originating IP address of a request or IP number of the proxy on the user-agent facing interface. Given a trusted path of proxying components, this makes it possible to arrange so that each subsequent component will have access to e.g., all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. | ||||||||||||||||
| draft-ietf-appsawg-json-patch-01.txt | |||||||||||||||||
| JSON Patch | |||||||||||||||||
|
JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document. | ||||||||||||||||
| draft-ietf-appsawg-json-pointer-01.txt | |||||||||||||||||
| JSON Pointer | |||||||||||||||||
|
JSON Pointer defines a string syntax for identifying a specific value within a JSON document. | ||||||||||||||||
| draft-ietf-appsawg-malformed-mail-02.txt | |||||||||||||||||
| Advice for Safe Handling of Malformed Messages | |||||||||||||||||
|
The email ecosystem has long had a very permissive set of common processing rules in place, despite increasingly rigid standards governing its components, ostensibly to improve the user experience. The handling of these come at some cost, and various components are 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. 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. 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 simply reject or discard them. Accordingly, this document presents recommendations for dealing with them in ways that seem to do the least additional harm until the infrastructure is tightened up to match the standards. | ||||||||||||||||
| draft-ietf-appsawg-media-type-regs-10.txt | |||||||||||||||||
| Media Type Specifications and Registration Procedures | |||||||||||||||||
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. | ||||||||||||||||
| draft-ietf-appsawg-media-type-suffix-regs-01.txt | |||||||||||||||||
| Additional Media Type Structured Syntax Suffixes | |||||||||||||||||
|
A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration. | ||||||||||||||||
| draft-ietf-appsawg-mime-default-charset-04.txt | |||||||||||||||||
| Update to MIME regarding Charset Parameter Handling in Textual Media Types | |||||||||||||||||
|
This document changes RFC 2046 rules regarding default charset parameter values for text/* media types to better align with common usage by existing clients and servers. Editorial Note (To be removed by RFC Editor) Discussion of this draft should take place on the Apps Area Working Group mailing list (apps-discuss@ietf.org), which is archived at | ||||||||||||||||
| draft-ietf-appsawg-received-state-01.txt | |||||||||||||||||
| Indicating Email Handling States in Trace Fields | |||||||||||||||||
|
This memo registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queueing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. | ||||||||||||||||
| draft-ietf-appsawg-xdash-05.txt | |||||||||||||||||
| Deprecating the X- Prefix and Similar Constructs in Application Protocols | |||||||||||||||||
|
Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly-defined parameters with textual (as opposed to numerical) names in application protocols. | ||||||||||||||||
| draft-ietf-armd-problem-statement-02.txt | |||||||||||||||||
| Problem Statement for ARMD | |||||||||||||||||
|
This document examines address resolution issues related to the massive scaling of data centers. Our initial scope is relatively narrow. Specifically, it focuses on address resolution (ARP and ND) within the data center. | ||||||||||||||||
| draft-ietf-atoca-requirements-03.txt | |||||||||||||||||
| Requirements,Terminology and Framework for Exigent Communications | |||||||||||||||||
|
Before, during and after emergency situations various agencies need to provide information to a group of persons or to the public within a geographical area. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document provides terminology, requirements and an architectural description for protocols exchanging alerts between IP-based end points. | ||||||||||||||||
| draft-ietf-avt-rtp-evrc-nw-06.txt | |||||||||||||||||
| RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) | |||||||||||||||||
|
This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. | ||||||||||||||||
| draft-ietf-avt-rtp-isac-01.txt | |||||||||||||||||
| RTP Payload Format for the iSAC Codec | |||||||||||||||||
|
iSAC is a proprietary wideband speech and audio codec developed by Global IP Solutions, suitable for use in Voice over IP applications. This document describes the payload format for iSAC generated bit streams within a Real-Time Protocol (RTP) packet. Also included here are the necessary details for the use of iSAC with the Session Description Protocol (SDP). | ||||||||||||||||
| draft-ietf-avt-srtp-not-mandatory-08.txt | |||||||||||||||||
| Why RTP Does Not Mandate a Single Security Mechanism | |||||||||||||||||
|
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. It also discusses how applications using RTP can meet the goals of BCP 61 to have strong and mandatory to implement security. | ||||||||||||||||
| draft-ietf-avtcore-aria-srtp-00.txt | |||||||||||||||||
| The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ietf-avtcore-ecn-for-rtp-08.txt | |||||||||||||||||
| Explicit Congestion Notification (ECN) for RTP over UDP | |||||||||||||||||
|
This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialization methods are also defined. | ||||||||||||||||
| draft-ietf-avtcore-feedback-supression-rtp-17.txt | |||||||||||||||||
| RTCP Extension for Third-party Loss Report | |||||||||||||||||
|
In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP third-party loss report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signaling is also defined. | ||||||||||||||||
| draft-ietf-avtcore-idms-04.txt | |||||||||||||||||
| RTCP for inter-destination media synchronization | |||||||||||||||||
|
This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for Inter-Destination Media Synchronization (IDMS). The RTCP XR Block Type, registered with IANA based on an ETSI specification, is used to collect media playout information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream. The RTCP packet type specified by this document is used 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 usefull 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. | ||||||||||||||||
| draft-ietf-avtcore-monarch-13.txt | |||||||||||||||||
| Monitoring Architecture for RTP | |||||||||||||||||
|
This memo proposes an architecture for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to report new metrics regarding media transmission or reception quality, following RTCP guideline established in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. | ||||||||||||||||
| draft-ietf-avtcore-srtp-aes-gcm-00.txt | |||||||||||||||||
| AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) | |||||||||||||||||
|
This document defines how AES-GCM, AES-CCM, and other Authenticated Encryption with Associated Data (AEAD) algorithms, can be used to provide confidentiality and data authentication mechanisms in the SRTP protocol. | ||||||||||||||||
| draft-ietf-avtext-multiple-clock-rates-05.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-avtext-rams-scenarios-05.txt | |||||||||||||||||
| Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method | |||||||||||||||||
|
The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios. | ||||||||||||||||
| draft-ietf-avtext-splicing-for-rtp-07.txt | |||||||||||||||||
| Content Splicing for RTP Sessions | |||||||||||||||||
|
This memo outlines RTP splicing. Splicing is a process that replaces the content of the main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to receiver for a period of time. This memo provides some RTP splicing use cases, then we enumerate a set of requirements and analyze whether an existing RTP level middlebox can meet these requirements, at last we provide concrete guidelines for how the chosen middlebox works to handle RTP splicing. | ||||||||||||||||
| draft-ietf-behave-64-analysis-07.txt | |||||||||||||||||
| Analysis of Stateful 64 Translation | |||||||||||||||||
|
Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. | ||||||||||||||||
| draft-ietf-behave-lsn-requirements-06.txt | |||||||||||||||||
| Common requirements for Carrier Grade NATs (CGNs) | |||||||||||||||||
|
This document defines common requirements for Carrier-Grade NAT (CGN). It updates RFC 4787. | ||||||||||||||||
| draft-ietf-behave-nat-mib-00.txt | |||||||||||||||||
| Additional Definitions of Managed Objects for Network Address Translators (NAT) | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ietf-behave-nat64-discovery-heuristic-09.txt | |||||||||||||||||
| Discovery of IPv6 Prefix Used for IPv6 Address Synthesis | |||||||||||||||||
|
This document describes a method for detecting presence of DNS64 and for learning IPv6 prefix used for protocol translation on an access network. The method depends on existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid traversal through NAT64 on dual-stack accesses and multi-interface deployments. | ||||||||||||||||
| draft-ietf-behave-nat64-learn-analysis-03.txt | |||||||||||||||||
| Analysis of solution proposals for hosts to learn NAT64 prefix | |||||||||||||||||
|
Hosts and applications may benefit from the knowledge if an IPv6 address is synthesized, which would mean a NAT64 is used to reach the IPv4 network or Internet. This document analyses a number of proposed solutions for communicating whether the synthesis is taking place, used address format, and the IPv6 prefix used by the NAT64 and DNS64. The solutions enable both NAT64 avoidance and intentional utilization by allowing local IPv6 address synthesis. The document concludes by recommending selection of heuristic discovery based solution. | ||||||||||||||||
| draft-ietf-behave-sctpnat-06.txt | |||||||||||||||||
| Stream Control Transmission Protocol (SCTP) Network Address Translation | |||||||||||||||||
|
Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point and multi-point traversal scenario. | ||||||||||||||||
| draft-ietf-bfcpbis-rfc4582bis-02.txt | |||||||||||||||||
| The Binary Floor Control Protocol (BFCP) | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ietf-bfcpbis-rfc4583bis-00.txt | |||||||||||||||||
| 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 15. | ||||||||||||||||
| draft-ietf-bfd-generic-crypto-auth-01.txt | |||||||||||||||||
| BFD Generic Cryptographic Authentication | |||||||||||||||||
|
This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure thats required for supporting algorithm and key agility for BFD. | ||||||||||||||||
| draft-ietf-bfd-hmac-sha-00.txt | |||||||||||||||||
| Authenticating BFD using HMAC-SHA-2 procedures | |||||||||||||||||
|
This document describes how Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms can be used for authenticating Bidirectional Forwarding Detection (BFD). It uses the Generic Cryptographic Authentication and Generic Meticulous Cryptographic Authentication sections to carry the authentication data. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 5880. | ||||||||||||||||
| draft-ietf-bliss-call-completion-14.txt | |||||||||||||||||
| Call Completion for Session Initiation Protocol (SIP) | |||||||||||||||||
|
The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'automatic redial' in the SIP Service Examples (RFC 5359). For the realization of a more comprehensive solution with queuing , this document introduces an architecture for implementing these features in the Session Initiation Protocol where "Call completion" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for call completion into a queue at the callee's endpoint, and when a caller's request is ready to be serviced, re-attempt of the original, failed call is made. The architecture is designed to interoperate well with existing call- completion solutions in other networks. | ||||||||||||||||
| draft-ietf-bliss-shared-appearances-10.txt | |||||||||||||||||
| Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) | |||||||||||||||||
|
This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements and defines extensions to implement this feature. | ||||||||||||||||
| draft-ietf-bmwg-2544-as-03.txt | |||||||||||||||||
| RFC 2544 Applicability Statement: Use on Production Networks Considered Harmful | |||||||||||||||||
|
Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. Recent application of the methods beyond their intended scope is cause for concern. This memo clarifies the scope of RFC 2544 and other benchmarking work for the IETF community. | ||||||||||||||||
| draft-ietf-bmwg-ca-bench-meth-01.txt | |||||||||||||||||
| Benchmarking Methodology for Content-Aware Network Devices | |||||||||||||||||
|
This document defines a set of test scenarios and metrics that can be used to benchmark content-aware network devices. The scenarios in the following document are intended to more accurately predict the performance of these devices when subjected to dynamic traffic patterns. This document will operate within the constraints of the Benchmarking Working Group charter, namely black box characterization in a laboratory environment. | ||||||||||||||||
| draft-ietf-bmwg-imix-genome-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-bmwg-ipflow-meth-10.txt | |||||||||||||||||
| IP Flow Information Accounting and Export Benchmarking Methodology | |||||||||||||||||
|
This document provides a methodology and framework for quantifying the performance impact of monitoring of IP flows on a network device and export of this information to a collector. It identifies the rate at which the IP flows are created, expired, and successfully exported as a new performance metric in combination with traditional throughput. The metric is only applicable to the devices compliant with the Architecture for IP Flow Information Export [RFC5470]. The methodology quantifies the impact of the IP flow monitoring process on the network equipment. | ||||||||||||||||
| draft-ietf-bmwg-protection-meth-09.txt | |||||||||||||||||
| Methodology for benchmarking MPLS protection mechanisms | |||||||||||||||||
|
This draft describes the methodology for benchmarking MPLS Protection mechanisms for link and node protection as defined in [MPLS-FRR-EXT]. This document provides test methodologies and testbed setup for measuring failover times while considering all dependencies that might impact faster recovery of real-time applications bound to MPLS based traffic engineered tunnels. The benchmarking terms used in this document are defined in [TERM-ID]. | ||||||||||||||||
| draft-ietf-bmwg-sip-bench-meth-04.txt | |||||||||||||||||
| Methodology for Benchmarking SIP Networking Devices | |||||||||||||||||
|
This document describes the methodology for benchmarking Session Initiation Protocol (SIP) performance as described in SIP benchmarking terminology document. The methodology and terminology are to be used for benchmarking signaling plane performance with varying signaling and media load. Both scale and establishment rate are measured by signaling plane performance. The SIP Devices to be benchmarked may be a single device under test (DUT) or a system under test (SUT). Benchmarks can be obtained and compared for different types of devices such as SIP Proxy Server, SBC, and server paired with a media relay or Firewall/NAT device. | ||||||||||||||||
| draft-ietf-bmwg-sip-bench-term-04.txt | |||||||||||||||||
| Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices | |||||||||||||||||
|
This document provides a terminology for benchmarking SIP performance in networking devices. Terms are included for test components, test setup parameters, and performance benchmark metrics for black-box benchmarking of SIP networking devices. The performance benchmark metrics are obtained for the SIP control plane and media plane. The terms are intended for use in a companion methodology document for complete performance characterization of a device in a variety of conditions making it possible to compare performance of different devices. It is critical to provide test setup parameters and a methodology document for SIP performance benchmarking because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. It is necessary to have terminology and methodology standards to ensure that reported benchmarks have consistent definition and were obtained following the same procedures. Benchmarks can be applied to compare performance of a variety of SIP networking devices. | ||||||||||||||||
| draft-ietf-ccamp-assoc-ext-03.txt | |||||||||||||||||
| RSVP Association Object Extensions | |||||||||||||||||
|
The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state, and this document defines how the ASSOCIATION object can be more generally applied. This document also defines extended ASSOCIATION objects which, in particular, can be used in the context of Transport Profile of Multiprotocol Label Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also modifies the definition of the Association ID field defined in RFC 4872. | ||||||||||||||||
| draft-ietf-ccamp-assoc-info-03.txt | |||||||||||||||||
| Usage of The RSVP Association Object | |||||||||||||||||
|
The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This document reviews how association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document and it is strictly informative in nature. | ||||||||||||||||
| draft-ietf-ccamp-dpm-05.txt | |||||||||||||||||
| Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ MPLS-TE Networks | |||||||||||||||||
|
When setting up a label switched path (LSP) in Generalized MPLS and MPLS/TE networks, the completion of the signaling process does not necessarily mean that the cross connection along the LSP have been programmed accordingly and in a timely manner. Meanwhile, the completion of signaling process may be used by applications as indication that data path has become usable. The existence of this delay and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the application model and to build more robust applications. This document defines a series of performance metrics to evaluate the availability of data path in the signaling process. | ||||||||||||||||
| draft-ietf-ccamp-general-constraint-encode-07.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-ccamp-gmpls-g709-framework-06.txt | |||||||||||||||||
| 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 consented in October 2009. | ||||||||||||||||
| draft-ietf-ccamp-gmpls-ospf-g709v3-02.txt | |||||||||||||||||
| Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks | |||||||||||||||||
|
The recent revision of ITU-T Recommendation G.709 [G709-V3] has introduced new fixed and flexible ODU containers, enabling optimized support for an increasingly abundant service mix. This document describes OSPF routing protocol extensions to support Generalized MPLS (GMPLS) control of all currently defined ODU containers, in support of both sub-lambda and lambda level routing granularity. | ||||||||||||||||
| draft-ietf-ccamp-gmpls-signaling-g709v3-02.txt | |||||||||||||||||
| Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control | |||||||||||||||||
|
Recent progress in ITU-T Recommendation G.709 standardization has introduced new ODU containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. Several recent documents have proposed ways to modify GMPLS signaling protocols to support these new OTN features. It is important that a single solution is developed for use in GMPLS signaling and routing protocols. This solution must support ODUk multiplexing capabilities, address all of the new features, be acceptable to all equipment vendors, and be extensible considering continued OTN evolution. This document describes the extensions to the Generalized Multi- Protocol Label Switching (GMPLS) signaling to control the evolving Optical Transport Networks (OTN) addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. | ||||||||||||||||
| draft-ietf-ccamp-gmpls-ted-mib-13.txt | |||||||||||||||||
| Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS | |||||||||||||||||
|
This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-Protocol Label Switching (MPLS) with traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. | ||||||||||||||||
| draft-ietf-ccamp-lmp-behavior-negotiation-05.txt | |||||||||||||||||
| Link Management Protocol Behavior Negotiation and Configuration Modifications | |||||||||||||||||
|
The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS) networks. This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations. | ||||||||||||||||
| draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03.txt | |||||||||||||||||
| RSVP-TE Extensions for Associated Bidirectional LSPs | |||||||||||||||||
|
The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], describes that MPLS-TP MUST support associated bidirectional point- to-point LSPs. This document provides a method to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining the new Association Types in the Extended ASSOCIATION object. | ||||||||||||||||
| draft-ietf-ccamp-oam-configuration-fwk-07.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-ccamp-otn-g709-info-model-03.txt | |||||||||||||||||
| Information model for G.709 Optical Transport Networks (OTN) | |||||||||||||||||
|
The recent revision of ITU-T recommendation G.709 [G.709-v3] has introduced new fixed and flexible ODU containers in Optical Transport Networks (OTNs), enabling optimized support for an increasingly abundant service mix. This document provides a model of information needed by the routing and signaling process in OTNs to support Generalized Multiprotocol Label Switching (GMPLS) control of all currently defined ODU containers. | ||||||||||||||||
| draft-ietf-ccamp-rfc5787bis-03.txt | |||||||||||||||||
| Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) | |||||||||||||||||
|
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. | ||||||||||||||||
| draft-ietf-ccamp-rsvp-te-eth-oam-ext-07.txt | |||||||||||||||||
| 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 to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities defining Ethernet technology specific TLV based on [OAM-CONF-FWK]. | ||||||||||||||||
| draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08.txt | |||||||||||||||||
| Configuration of Pro-Active Operations,Administration,and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE | |||||||||||||||||
|
This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the RSVP-TE protocol. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication 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. | ||||||||||||||||
| draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-04.txt | |||||||||||||||||
| GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration | |||||||||||||||||
|
GMPLS has been extended to support connection establishment in both SONET/SDH [RFC4606] and OTN [RFC4328] networks. However support for the configuration of the supervision functions is not specified. Both SONET/SDH and OTN implement supervision functions to qualify the transported signals. This document defines extensions to RSVP-TE for SONET/SDH and OTN OAM configuration based on the OAM Configuration Framework defined in [GMPLS-OAM-FWK]. | ||||||||||||||||
| draft-ietf-ccamp-rwa-info-14.txt | |||||||||||||||||
| Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ietf-ccamp-rwa-wson-encode-14.txt | |||||||||||||||||
| Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks | |||||||||||||||||
|
A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are fairly specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). | ||||||||||||||||
| draft-ietf-ccamp-wson-signal-compatibility-ospf-08.txt | |||||||||||||||||
| GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks | |||||||||||||||||
|
This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. | ||||||||||||||||
| draft-ietf-ccamp-wson-signaling-03.txt | |||||||||||||||||
| Signaling Extensions for Wavelength Switched Optical Networks | |||||||||||||||||
|
This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Such extensions are necessary in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment with bidirectional LSPs, and choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. | ||||||||||||||||
| draft-ietf-cdni-framework-00.txt | |||||||||||||||||
| Framework for CDN Interconnection | |||||||||||||||||
|
This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, metadata exchange, and the acquisition of content by one CDN from another. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. | ||||||||||||||||
| draft-ietf-cdni-problem-statement-06.txt | |||||||||||||||||
| Content Distribution Network Interconnection (CDNI) Problem Statement | |||||||||||||||||
|
Content Delivery Networks (CDNs) provide numerous benefits: reduced delivery cost for cacheable content, improved quality of experience for End Users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. The goal of this document is to outline the problem area of CDN interconnection for the IETF CDNI (CDN Interconnection) working group. | ||||||||||||||||
| draft-ietf-cdni-requirements-02.txt | |||||||||||||||||
| Content Distribution Network Interconnection (CDNI) Requirements | |||||||||||||||||
|
Content Delivery Networks (CDNs) are frequently used for large-scale content delivery. As a result, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. There is a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. The Content Distribution Network Interconnection (CDNI) working group has been chartered to develop an interoperable and scalable solution for such CDN interconnection. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. This draft is a work in progress and requirements may be added, modified, or removed by the working group. Requirements Language The key words "High Priority", "Medium Priority" and "Low Priority" in this document are to be interpreted in the following way: o "High Priority" indicates requirements that are to be supported by the CDNI interfaces. A requirement is stated as "High Priority" when it is established by the working group that it can be met without compromising the targeted schedule for WG deliverables, or when it is established that specifying a solution without meeting this requirement would not make sense and would justify re- adjusting the WG schedule, or both. This is tagged as "[HIGH]". o "Medium Priority" indicates requirements that are to be supported by the CDNI interfaces unless the WG realizes at a later stage that attempting to meet this requirement would compromise the overall WG schedule (for example it would involve complexities that would result in significantly delaying the deliverables). This is tagged as "[MED]". o "Low Priority" indicates requirements that are to be supported by the CDNI interfaces provided that dedicating WG resources to this work does not prevent addressing "High Priority" and "Medium Priority" requirements and that attempting to meet this requirement would not compromise the overall WG schedule. This is tagged as "[LOW]". | ||||||||||||||||
| draft-ietf-cdni-use-cases-06.txt | |||||||||||||||||
| Use Cases for Content Delivery Network Interconnection | |||||||||||||||||
|
Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service, at a reasonable cost. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting interconnection of CDNs are specified and implemented. The document can be used to guide the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. | ||||||||||||||||
| draft-ietf-clue-framework-05.txt | |||||||||||||||||
| Framework for Telepresence Multi-Streams | |||||||||||||||||
|
This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. | ||||||||||||||||
| draft-ietf-clue-telepresence-use-cases-02.txt | |||||||||||||||||
| Use Cases for Telepresence Multi-streams | |||||||||||||||||
|
Telepresence conferencing systems seek to create the sense of really being present for the participants. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. | ||||||||||||||||
| draft-ietf-codec-opus-14.txt | |||||||||||||||||
| Definition of the Opus Audio Codec | |||||||||||||||||
|
This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. | ||||||||||||||||
| draft-ietf-codec-results-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-conex-abstract-mech-04.txt | |||||||||||||||||
| Congestion Exposure (ConEx) Concepts and Abstract Mechanism | |||||||||||||||||
|
This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ECN markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called congestion exposure or ConEx. The companion document "ConEx Concepts and Use Cases" provides the entry-point to the set of ConEx documentation. | ||||||||||||||||
| draft-ietf-conex-concepts-uses-04.txt | |||||||||||||||||
| ConEx Concepts and Use Cases | |||||||||||||||||
|
This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. | ||||||||||||||||
| draft-ietf-conex-destopt-02.txt | |||||||||||||||||
| IPv6 Destination Option for Conex | |||||||||||||||||
|
Conex is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying conex markings in IPv6 datagrams. | ||||||||||||||||
| draft-ietf-conex-tcp-modifications-02.txt | |||||||||||||||||
| 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). | ||||||||||||||||
| draft-ietf-core-block-08.txt | |||||||||||||||||
| Blockwise transfers in CoAP | |||||||||||||||||
|
CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. | ||||||||||||||||
| draft-ietf-core-coap-09.txt | |||||||||||||||||
| Constrained Application Protocol (CoAP) | |||||||||||||||||
|
This document specifies the Constrained Application Protocol (CoAP), a specialized web transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides a method/response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. | ||||||||||||||||
| draft-ietf-core-groupcomm-01.txt | |||||||||||||||||
| Group Communication for CoAP | |||||||||||||||||
|
This is a working document intended to develop draft text for the CoAP protocol specification in the area of group communication. A solution based on IP multicast is proposed and detailed. Also, guidance is provided for deployment in various constrained network topologies. | ||||||||||||||||
| draft-ietf-core-link-format-13.txt | |||||||||||||||||
| CoRE Link Format | |||||||||||||||||
|
This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header field defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well-known URI is defined as a default entry-point for requesting the links hosted by a server. | ||||||||||||||||
| draft-ietf-core-observe-05.txt | |||||||||||||||||
| Observing Resources in CoAP | |||||||||||||||||
|
CoAP is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that gives clients the ability to observe such changes. | ||||||||||||||||
| draft-ietf-csi-dhcpv6-cga-ps-09.txt | |||||||||||||||||
| Analysis of Possible DHCPv6 and CGA Interactions | |||||||||||||||||
|
This document analyzes the possible interactions between DHCPv6 and Cryptographically Generated Addresses (CGAs), and gives recommendations on whether or not these interactions should be developed as solutions. | ||||||||||||||||
| draft-ietf-cuss-sip-uui-06.txt | |||||||||||||||||
| A Mechanism for Transporting User to User Call Control Information in SIP | |||||||||||||||||
|
There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The rules which apply for a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. | ||||||||||||||||
| draft-ietf-cuss-sip-uui-isdn-04.txt | |||||||||||||||||
| Interworking ISDN Call Control User Information with SIP | |||||||||||||||||
|
The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. | ||||||||||||||||
| draft-ietf-dane-protocol-21.txt | |||||||||||||||||
| The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA | |||||||||||||||||
|
Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. | ||||||||||||||||
| draft-ietf-dccp-udpencap-10.txt | |||||||||||||||||
| Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) | |||||||||||||||||
|
This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the SDP information for DCCP defined in RFC 5762. | ||||||||||||||||
| draft-ietf-decade-arch-05.txt | |||||||||||||||||
| DECADE Architecture | |||||||||||||||||
|
Content Distribution Applications (e.g., P2P applications) are widely used on the Internet and make up a large portion of the traffic in many networks. One technique to improve the network efficiency of these applications is to introduce storage capabilities within the networks; this is the capability to be provided by a DECADE (DECoupled Application Data Enroute) compliant system. This document presents an architecture for DECADE, discusses the underlying principles, and identifies key functionalities required for introducing in-network storage for these applications. In addition, some examples are given to illustrate these concepts in an informative manner. | ||||||||||||||||
| draft-ietf-decade-integration-example-03.txt | |||||||||||||||||
| Integration Examples of DECADE System | |||||||||||||||||
|
Decoupled Application Data Enroute (DECADE) system is an in-network storage infrastructure which is still under discussion and standardization process in IETF DECADE WG. This document presents two detailed examples of how to integrate such in-network storage infrastructure into peer-to-peer (P2P) applications to achieve more efficient content distribution, and Application Layer Traffic Optimization (ALTO) system to build a content distribution platform for Content Providers (CPs). | ||||||||||||||||
| draft-ietf-decade-problem-statement-06.txt | |||||||||||||||||
| DECoupled Application Data Enroute (DECADE) Problem Statement | |||||||||||||||||
|
Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols and cache refresh mechanisms) and they do not allow users to manage access to content in the cache. For example, content providers wishing to use in- network storage cannot easily control cache access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, and shows the need for a standard protocol for accessing this storage. | ||||||||||||||||
| draft-ietf-decade-reqs-06.txt | |||||||||||||||||
| DECADE Requirements | |||||||||||||||||
|
The target of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage system for applications, primarily P2P (peer-to-peer) applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for storage and retrieval, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE- compatible system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., a protocol used to read and write data from the storage system). The requirements in this document are intended to ensure that a DECADE-compatible system architecture includes all of the desired functionality for intended applications. | ||||||||||||||||
| draft-ietf-dhc-addr-registration-00.txt | |||||||||||||||||
| A Generic IPv6 Addresses Registration Solution Using DHCPv6 | |||||||||||||||||
|
In the IPv6 address allocation scenarios, host self-generated addresses are notionally conflicted with the network managed address architecture. These addresses need to be registered in the networking management plate for the purposes of central address administration. This document introduces a generic address registration solution using DHCPv6, and defines one new ND option and one new DHCPv6 option in order to propagate the solicitations of registering self-generated addresses. The registration procedure reuses the existing IA_NA in the DHCPv6 protocol. | ||||||||||||||||
| draft-ietf-dhc-cga-config-dhcpv6-02.txt | |||||||||||||||||
| Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 | |||||||||||||||||
|
A Cryptographically Generated Address is an IPv6 addresses binding with a public/private key pair. However, the current CGA specifications are lack of procedures to enable proper management of the usage of CGAs. This document defines the process using DHCPv6 to manage CGAs in detail. A new DHCPv6 option is defined accordingly. This document also analyses the configuration of the parameters, which are used to generate CGAs, using DHCPv6. Although the document does not define new DHCPv6 option to carry these parameters for various reasons, the configuration procedure is described. | ||||||||||||||||
| draft-ietf-dhc-client-id-02.txt | |||||||||||||||||
| Client Identifier Option in DHCP Server Replies | |||||||||||||||||
|
This document updates RFC2131 [RFC2131]. The changes to [RFC2131] defined in this draft clarifies the use of 'client identifier' option by the DHCP servers. The clarification addresses the issues arising out of the point specified by [RFC2131] that the server 'MUST NOT' return client identifier' option to the client. Requirements | ||||||||||||||||
| draft-ietf-dhc-dhcpv4-bulk-leasequery-06.txt | |||||||||||||||||
| Bulk DHCPv4 Lease Query | |||||||||||||||||
|
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery extension allows a requestor to request information about DHCPv4 bindings. This mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. | ||||||||||||||||
| draft-ietf-dhc-dhcpv4-over-ipv6-03.txt | |||||||||||||||||
| DHCPv4 over IPv6 Transport | |||||||||||||||||
|
In IPv6 networks, there remains a need to provide IPv4 service for some residual devices. This document describes a mechanism for allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 transport. It is done by putting a special relay agent function (Client Relay Agent) on the client side, as well as extending the behavior of the server; in the case where DHCP server only supports IPv4 transport, a relay agent is extended to support IPv6 transport (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, with a new Relay Agent Information sub-option added to carry the IPv6 address of the Client Relay Agent. | ||||||||||||||||
| draft-ietf-dhc-dhcpv6-radius-opt-00.txt | |||||||||||||||||
| RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server | |||||||||||||||||
|
The DHCPv6 RADIUS option provides a communication mechanism between relay agent and the server. This mechanism can help the centralized DHCPv6 server to select the right configuration for the client based on the authorization information received from a separate RADIUS server which is not located at the same place of DHCPv6 server in the cases where the NAS acts as DHCPv6 relay agent and RADIUS client simultaneously. | ||||||||||||||||
| draft-ietf-dhc-dhcpv6-reconfigure-rebind-10.txt | |||||||||||||||||
| Rebind Capability in DHCPv6 Reconfigure Messages | |||||||||||||||||
|
This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. | ||||||||||||||||
| draft-ietf-dhc-dhcpv6-redundancy-consider-02.txt | |||||||||||||||||
| DHCPv6 Redundancy Deployment Considerations | |||||||||||||||||
|
This document documents some deployment considerations for those who wishing to use DHCPv6 to support their deployment of IPv6. Specifically, providing semi-redundant DHCPv6 services is discussed in this document. | ||||||||||||||||
| draft-ietf-dhc-dhcpv6-stateful-issues-00.txt | |||||||||||||||||
| 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 has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. | ||||||||||||||||
| draft-ietf-dhc-dhcpv6-tunnel-01.txt | |||||||||||||||||
| DHCPv6 through Tunnels | |||||||||||||||||
|
The host configuration protocol DHCPv6 [RFC3315] relies on link-local addresses as source addresses and multicast addresses for destination addresses. However, some tunnel links (e.g., 6rd [RFC5969] ) do not have IPv6 link-local addresses and do not support IPv6 multicast addresses. Taking 6rd as an example, this document specifies how DHCPv6 is used across such tunnel links. | ||||||||||||||||
| draft-ietf-dhc-forcerenew-nonce-06.txt | |||||||||||||||||
| Forcerenew Nonce Authentication | |||||||||||||||||
|
Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In Forcerenew Nonce Authentication the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. | ||||||||||||||||
| draft-ietf-dhc-host-gen-id-02.txt | |||||||||||||||||
| Prefix Assignment in DHCPv6 | |||||||||||||||||
|
This document introduce a procedure for configuring hosts' IPv6 address which the prefix is assigned from a DHCPv6 server through DHCPv6 protocol while the interface identifiers are independently generated by the hosts. The method is applicable to Cryptographically Generated Addresses (CGA), and other IPv6 addresses with host-generated interface identifiers. | ||||||||||||||||
| draft-ietf-dhc-l2ra-06.txt | |||||||||||||||||
| Layer 2 Relay Agent Information | |||||||||||||||||
|
In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when end hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the device that is closest to the end hosts to append a Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where a Layer 2 Relay Agent is in use and also how it handles DHCP messages. | ||||||||||||||||
| draft-ietf-dhc-relay-id-suboption-10.txt | |||||||||||||||||
| The DHCPv4 Relay Agent Identifier Suboption | |||||||||||||||||
|
This draft defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively-configured in the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. | ||||||||||||||||
| draft-ietf-dhc-secure-dhcpv6-06.txt | |||||||||||||||||
| Secure DHCPv6 Using CGAs | |||||||||||||||||
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attack. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism based on using CGAs. | ||||||||||||||||
| draft-ietf-dhc-subnet-alloc-13.txt | |||||||||||||||||
| Description of Cisco Systems' Subnet Allocation Option for DHCPv4 | |||||||||||||||||
|
This memo documents a currently existing and previously privately defined DHCPv4 option, documenting the operation and usage of the Cisco Systems Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. | ||||||||||||||||
| draft-ietf-dime-app-design-guide-14.txt | |||||||||||||||||
| 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 the Diameter Base protocol. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. | ||||||||||||||||
| draft-ietf-dime-capablities-update-07.txt | |||||||||||||||||
| The Diameter Capabilities Update Application | |||||||||||||||||
|
This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. | ||||||||||||||||
| draft-ietf-dime-erp-09.txt | |||||||||||||||||
| Diameter Support for the EAP Re-authentication Protocol (ERP) | |||||||||||||||||
|
The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. | ||||||||||||||||
| draft-ietf-dime-ikev2-psk-diameter-11.txt | |||||||||||||||||
| Diameter IKEv2 SK: Shared Key-based Support for IKEv2 Server to Diameter Server Interaction | |||||||||||||||||
|
The Internet Key Exchange protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec security associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and shared key. Diameter interworking for Mobile IPv6 between the Home Agent, as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for shared key based authentication available with IKEv2. This document specifies the IKEv2 Server to the Diameter server communication when the IKEv2 Peer authenticates using the Internet Key Exchange v2 with Shared Key. | ||||||||||||||||
| draft-ietf-dime-local-keytran-14.txt | |||||||||||||||||
| Diameter Attribute-Value Pairs for Cryptographic Key Transport | |||||||||||||||||
|
Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. | ||||||||||||||||
| draft-ietf-dime-nat-control-17.txt | |||||||||||||||||
| Diameter Network Address and Port Translation Control Application | |||||||||||||||||
|
This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4-address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA- servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. | ||||||||||||||||
| draft-ietf-dime-pmip6-lr-13.txt | |||||||||||||||||
| Diameter Support for Proxy Mobile IPv6 Localized Routing | |||||||||||||||||
|
In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, the usage of localized routing may be authorized for both MAGs. This document specifies how to accomplish this using the Diameter protocol. | ||||||||||||||||
| draft-ietf-dime-priority-avps-05.txt | |||||||||||||||||
| Diameter Priority Attribute Value Pairs | |||||||||||||||||
|
This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. | ||||||||||||||||
| draft-ietf-dime-realm-based-redirect-04.txt | |||||||||||||||||
| Realm-Based Redirection In Diameter | |||||||||||||||||
|
RFC 3588 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. | ||||||||||||||||
| draft-ietf-dime-rfc3588bis-33.txt | |||||||||||||||||
| Diameter Base Protocol | |||||||||||||||||
|
The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719 and must be supported by all new Diameter implementations. | ||||||||||||||||
| draft-ietf-dime-rfc4005bis-09.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-dnsext-dnssec-algo-imp-status-02.txt | |||||||||||||||||
| Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status | |||||||||||||||||
|
The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that is incomplete in that it lacks the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. | ||||||||||||||||
| draft-ietf-dnsext-dnssec-algo-signal-06.txt | |||||||||||||||||
| Signaling Cryptographic Algorithm Understanding in DNSSEC | |||||||||||||||||
|
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms and hash algorithms they support. | ||||||||||||||||
| draft-ietf-dnsext-dnssec-bis-updates-18.txt | |||||||||||||||||
| Clarifications and Implementation Notes for DNSSECbis | |||||||||||||||||
|
This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. This document updates the core DNSSECbis documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification. | ||||||||||||||||
| draft-ietf-dnsext-dnssec-registry-update-02.txt | |||||||||||||||||
| DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates | |||||||||||||||||
|
The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA maintained registry. This document presents a set of changes for some entries of the registry. | ||||||||||||||||
| draft-ietf-dnsext-rfc1995bis-ixfr-01.txt | |||||||||||||||||
| DNS Incremental Zone Transfer Protocol (IXFR) | |||||||||||||||||
|
The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Incremental Zone Transfer (IXFR) is one of the mechanisms and originally was defined in RFC 1995. This document aims to provide a more detailed and up-to-date specification of the IXFR mechanism and to align it with the current specification of the primary zone transfer mechanism, AXFR, given in RFC 5936. Further, based on operational experience, this document juxtaposes to the original IXFR query a new query type, IXFR-ONLY, that will likely be preferred over IXFR in specific deployments. This document obsoletes and replaces RFC 1995. | ||||||||||||||||
| draft-ietf-dnsext-rfc2671bis-edns0-08.txt | |||||||||||||||||
| Extension Mechanisms for DNS (EDNS0) | |||||||||||||||||
|
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification (RFC 2671) based on feedback from deployment experience in several implementations. It also closes the IANA registry for extended labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name System") which depends on the existence of extended labels. | ||||||||||||||||
| draft-ietf-dnsext-rfc2672bis-dname-26.txt | |||||||||||||||||
| DNAME Redirection in the DNS | |||||||||||||||||
|
The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision to the original specification in RFC 2672 (which this document obsoletes) as well as updating RFC 3363 and RFC 4294 to align with this revision. | ||||||||||||||||
| draft-ietf-dnsext-rfc6195bis-01.txt | |||||||||||||||||
| Domain Name System (DNS) IANA Considerations | |||||||||||||||||
|
This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195. | ||||||||||||||||
| draft-ietf-dnsop-dnssec-dps-framework-07.txt | |||||||||||||||||
| DNSSEC Policy & Practice Statement Framework | |||||||||||||||||
|
This document presents a framework to assist writers of DNSSEC Policy and Practice Statements such as Domain Managers and Zone Operators on both the top-level and secondary level, who is managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. | ||||||||||||||||
| draft-ietf-dnsop-respsize-14.txt | |||||||||||||||||
| DNS Referral Response Size Issues | |||||||||||||||||
|
With a mandated default minimum maximum UDP message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit, and suggests ways to optimize the use of this limited space. Guidance is offered to DNS server implementors and to DNS zone operators. | ||||||||||||||||
| draft-ietf-dnsop-rfc4641bis-11.txt | |||||||||||||||||
| DNSSEC Operational Practices,Version 2 | |||||||||||||||||
|
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. | ||||||||||||||||
| draft-ietf-drinks-spp-framework-01.txt | |||||||||||||||||
| Session Peering Provisioning Framework (SPPF) | |||||||||||||||||
|
This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session peering. | ||||||||||||||||
| draft-ietf-drinks-spp-protocol-over-soap-01.txt | |||||||||||||||||
| Session Peering Provisioning (SPP) Protocol over SOAP | |||||||||||||||||
|
The Session Peering Provisioning Framework (SPPF) is an XML framework that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport protocol for SPPF is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPF XML structures over SOAP and HTTP(s). | ||||||||||||||||
| draft-ietf-eai-5738bis-03.txt | |||||||||||||||||
| IMAP Support for UTF-8 | |||||||||||||||||
|
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses and message headers. This specification replaces RFC 5738. | ||||||||||||||||
| draft-ietf-eai-mailinglistbis-01.txt | |||||||||||||||||
| Mailing Lists and UTF-8 Addresses | |||||||||||||||||
|
This document describes considerations for mailing lists with the introduction of internationalized email addresses. It outlines some possible scenarios for handling lists with mixtures of internationalized and traditional addresses, but does not offer implementation or deployment advice. | ||||||||||||||||
| draft-ietf-eai-popimap-downgrade-05.txt | |||||||||||||||||
| Post-delivery Message Downgrading for Internationalized Email Messages | |||||||||||||||||
|
The Email Address Internationalization (SMTPUTF8) extension allows UTF-8 characters in mail header fields. Upgraded POP and IMAP servers support internationalized Email messages. If a POP/IMAP client does not support Email Address Internationalization, POP/IMAP servers cannot send Internationalized Email Headers to the client and cannot remove the message. To avoid the situation, this document describes a conversion mechanism for internationalized Email messages to be in traditional message format. In the process, message elements requiring internationalized treatment are recoded or removed and receivers are able to know that they received messages containing such elements even if they cannot treat the internationalized elements. | ||||||||||||||||
| draft-ietf-eai-rfc5721bis-04.txt | |||||||||||||||||
| POP3 Support for UTF-8 | |||||||||||||||||
|
This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual strings. | ||||||||||||||||
| draft-ietf-eai-simpledowngrade-04.txt | |||||||||||||||||
| EAI: Simplified POP/IMAP downgrading | |||||||||||||||||
|
This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement and provides only rudimentary results. | ||||||||||||||||
| draft-ietf-ecrit-additional-data-03.txt | |||||||||||||||||
| 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 service provider in the path of the call, or access network may have information about the call which the PSAP may be able to use. This document describes an XML data structure that contains this kind of information in a standardized form. A Uniform Resource Identifier (URI) that points to the structure can be included in the SIP signaling with the call, or the data may be included in the body of a SIP message. | ||||||||||||||||
| draft-ietf-ecrit-data-only-ea-03.txt | |||||||||||||||||
| Data-Only Emergency Calls | |||||||||||||||||
|
RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) can handle Internet multimedia emergency calls natively. The exchange of multimedia traffic typically involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is everything that is needed. Examples of such environments include a temperature sensors issuing alerts, or vehicles sending crash data. Often these alerts are conveyed as one-shot data transmissions and in some rare cases they may require a session to be established. These type of interactions are called 'data-only emergency calls'. | ||||||||||||||||
| draft-ietf-ecrit-lost-sync-17.txt | |||||||||||||||||
| Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements | |||||||||||||||||
|
The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the | ||||||||||||||||
| draft-ietf-ecrit-phonebcp-20.txt | |||||||||||||||||
| Best Current Practice for Communications Services in support of Emergency Calling | |||||||||||||||||
|
The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services using IETF protocols should use such standards to make emergency calls. | ||||||||||||||||
| draft-ietf-ecrit-psap-callback-04.txt | |||||||||||||||||
| Public Safety Answering Point (PSAP) Callback | |||||||||||||||||
|
After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current situation of a wounded person. A call taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than- normal call treatment behavior would be desirable. Note that this version of the document does not yet specify a solution due to the lack of the working group participants agreeing on the requirements. | ||||||||||||||||
| draft-ietf-ecrit-trustworthy-location-03.txt | |||||||||||||||||
| Trustworthy Location Information | |||||||||||||||||
|
For some location-based applications, such as emergency calling or roadside assistance, it is important to be able to determine whether location information is trustworthy. This document outlines potential threats to trustworthy location and analyzes the operational issues with potential solutions. | ||||||||||||||||
| draft-ietf-ecrit-unauthenticated-access-04.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-eman-applicability-statement-00.txt | |||||||||||||||||
| Energy Management (EMAN) Applicability Statement | |||||||||||||||||
|
The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework for a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. | ||||||||||||||||
| draft-ietf-eman-battery-mib-05.txt | |||||||||||||||||
| Definition of Managed Objects for Battery Monitoring | |||||||||||||||||
|
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 managed objects that provide information on the status of batteries in managed devices. | ||||||||||||||||
| draft-ietf-eman-energy-aware-mib-05.txt | |||||||||||||||||
| Energy Object Context MIB | |||||||||||||||||
|
This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the relationships between reporting devices, remote devices, and monitoring devices. | ||||||||||||||||
| draft-ietf-eman-energy-monitoring-mib-02.txt | |||||||||||||||||
| Power and Energy Monitoring MIB | |||||||||||||||||
|
This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. | ||||||||||||||||
| draft-ietf-eman-framework-04.txt | |||||||||||||||||
| Energy Management Framework | |||||||||||||||||
|
This document defines a framework for providing Energy Management for devices within or connected to communication networks, and components thereof. The framework defines an Energy Management Domain as a set of Energy Objects, for which each Energy Object is identified, classified and given context. Energy Objects can be monitored and/or controlled with respect to Power, Power State, Energy, Demand, Power Quality, and battery. Additionally the framework models relationships and capabilities between Energy Objects. | ||||||||||||||||
| draft-ietf-eman-requirements-06.txt | |||||||||||||||||
| Requirements for Energy Management | |||||||||||||||||
|
This document defines requirements for standards specifications for energy management. The requirements defined in this document concern monitoring functions as well as control functions. In detail, the focus of the requirements is on the following features: identification of powered entities, monitoring of their power state, power inlets, power outlets, actual power, power properties, consumed energy, and contained batteries. Further requirements are included to enable control of powered entities' power supply and power state. 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. | ||||||||||||||||
| draft-ietf-emu-chbind-16.txt | |||||||||||||||||
| Channel Binding Support for EAP Methods | |||||||||||||||||
|
This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying Network Access Service (NAS) as well as the lying provider problem. | ||||||||||||||||
| draft-ietf-emu-eap-tunnel-method-02.txt | |||||||||||||||||
| Tunnel EAP Method (TEAP) Version 1 | |||||||||||||||||
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. | ||||||||||||||||
| draft-ietf-emu-eaptunnel-req-09.txt | |||||||||||||||||
| Requirements for a Tunnel Based EAP Method | |||||||||||||||||
|
This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. | ||||||||||||||||
| draft-ietf-fecframe-config-signaling-08.txt | |||||||||||||||||
| Methods to convey FEC Framework Configuration Information | |||||||||||||||||
|
FEC Framework document [RFC6363] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes using existing signaling protocols such as Session Announcement Protocol (SAP), Session Initiation Protocol (SIP), Real Time Stream Protocol (RTSP) etc. to determine and dynamically communicate the Configuration information between sender(s) and receiver(s). | ||||||||||||||||
| draft-ietf-fecframe-dvb-al-fec-04.txt | |||||||||||||||||
| Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection | |||||||||||||||||
|
The Annex E of the Digital Video Broadcasting (DVB)-IPTV technical specification defines an optional Application-layer Forward Error Correction (AL-FEC) protocol to protect the streaming media carried over RTP transport. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers a good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. | ||||||||||||||||
| draft-ietf-fecframe-ldpc-02.txt | |||||||||||||||||
| Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME | |||||||||||||||||
|
This document describes a fully-specified simple FEC scheme for LDPC- Staircase codes that can be used to protect media streams along the lines defined by the FECFRAME framework. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow, or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum. | ||||||||||||||||
| draft-ietf-fecframe-pseudo-cdp-03.txt | |||||||||||||||||
| Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework | |||||||||||||||||
|
This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-pledged protocol, but to show how the defined framework and SDP elements can be combined together to design a CDP. | ||||||||||||||||
| draft-ietf-fecframe-raptor-11.txt | |||||||||||||||||
| Raptor FEC Schemes for FECFRAME | |||||||||||||||||
|
This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined, two for protection of arbitrary packet flows, two that are optimised for small source blocks and another two for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. | ||||||||||||||||
| draft-ietf-fecframe-rtp-raptor-07.txt | |||||||||||||||||
| RTP Payload Format for Raptor FEC | |||||||||||||||||
|
This document specifies an RTP Payload Format for Forward Error Correction repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the Payload Format which is required for the use of RTP to carry Raptor repair flows. | ||||||||||||||||
| draft-ietf-fecframe-simple-rs-03.txt | |||||||||||||||||
| Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME | |||||||||||||||||
|
This document describes a fully-specified simple FEC scheme for Reed- Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by the FECFRAME framework. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against packet erasures. They are also systematic codes, which means that the source symbols are part of the encoding symbols. The price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of LDPC codes for instance. | ||||||||||||||||
| draft-ietf-forces-ceha-03.txt | |||||||||||||||||
| ForCES Intra-NE High Availability | |||||||||||||||||
|
This document discusses CE High Availability within a ForCES NE. | ||||||||||||||||
| draft-ietf-forces-interop-03.txt | |||||||||||||||||
| Interoperability Report for Forwarding and Control Element Separation (ForCES) | |||||||||||||||||
|
This document captures test results from the second Forwarding and control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. | ||||||||||||||||
| draft-ietf-forces-lfb-lib-09.txt | |||||||||||||||||
| ForCES Logical Function Block (LFB) Library | |||||||||||||||||
|
This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to ForCES FE model and ForCES protocol specifications, and are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. | ||||||||||||||||
| draft-ietf-ftpext2-ftp64-02.txt | |||||||||||||||||
| FTP consideration for IPv4/IPv6 transition | |||||||||||||||||
|
The File transfer protocol(FTP) has a long histroy,, but still being widely used. The first concept of FTP was described RFC 114, and then was specified in RFC 354. FTP can work in IPv4 environment and then was extended to IPv6. RFC 2428 defines IPv6 extensions of FTP. In the IPv6-IPv4 translation scenario, considerations should be applied to FTP client, server and translation box to ensure FTP protocol work properly. This document discusses the details for FTP to work in IPv4-IPv6 transitiion scenario. This document gives recommendation regarding how IPv6 FTP client should behave in 6to4 scenario. | ||||||||||||||||
| draft-ietf-ftpext2-hosts-05.txt | |||||||||||||||||
| File Transfer Protocol HOST Command for Virtual Hosts | |||||||||||||||||
|
The File Transfer Protocol, as defined in RFC 959 [RFC0959], 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. | ||||||||||||||||
| draft-ietf-ftpext2-typeu-03.txt | |||||||||||||||||
| FTP TYPE Extension for Internationalized Text | |||||||||||||||||
|
The traditional FTP protocol includes a TYPE command to specify the data representation. That command has values for ASCII and EBCDIC text, plus binary ("IMAGE") transmission. As the Internet becomes more international, there is a growing requirement to be able to transmit textual data, encoded in Unicode, in a way that is independent of the coding and line representation forms of particular operating systems. This memo specifies a new FTP representation TYPE value for Unicode data. | ||||||||||||||||
| draft-ietf-geopriv-deref-protocol-05.txt | |||||||||||||||||
| A Location Dereferencing Protocol Using HELD | |||||||||||||||||
|
This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. | ||||||||||||||||
| draft-ietf-geopriv-dhcp-lbyr-uri-option-14.txt | |||||||||||||||||
| Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI) | |||||||||||||||||
|
This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource Identifier (URI). This Location URI can then be dereferenced in a separate transaction by the client or sent to another entity and dereferenced to learn physically where the client is located. | ||||||||||||||||
| draft-ietf-geopriv-local-civic-03.txt | |||||||||||||||||
| Specifying Civic Address Extensions in PIDF-LO | |||||||||||||||||
|
New fields are occasionally added to civic addresses. A backwardly- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Intial extensions for some new elements are also defined. The LoST protocol mechanism that returns civic address element names used for validation of location information is clarified to require a namespace on each element. | ||||||||||||||||
| draft-ietf-geopriv-policy-25.txt | |||||||||||||||||
| Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information | |||||||||||||||||
|
This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information while the other one applies to geodetic location information. Both algorithms come with limitations, i.e. they provide location obfuscation under certain conditions and may therefore not be appropriate for all application domains. | ||||||||||||||||
| draft-ietf-geopriv-policy-uri-04.txt | |||||||||||||||||
| Location Configuration Extensions for Policy Management | |||||||||||||||||
|
Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules. | ||||||||||||||||
| draft-ietf-geopriv-res-gw-lis-discovery-03.txt | |||||||||||||||||
| Location Information Server (LIS) Discovery using IP address and Reverse DNS | |||||||||||||||||
|
The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device. | ||||||||||||||||
| draft-ietf-grow-bgp-gshut-03.txt | |||||||||||||||||
| Graceful BGP session shutdown | |||||||||||||||||
|
This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers or links, involving the shutdown of BGP peering sessions. | ||||||||||||||||
| draft-ietf-grow-bmp-06.txt | |||||||||||||||||
| BGP Monitoring Protocol | |||||||||||||||||
|
This document proposes a simple protocol, BMP, which can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen-scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. | ||||||||||||||||
| draft-ietf-grow-diverse-bgp-path-dist-07.txt | |||||||||||||||||
| Distribution of diverse BGP paths. | |||||||||||||||||
|
The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today BGP has no mechanisms to distribute alternate paths which are not considered best path between its speakers. This behaviour results in number of disadvantages for new applications and services. This document presents an alternative mechanism for solving the problem based on the concept of parallel route reflector planes. Such planes can be built in parallel or they can co-exist on the current route reflection platforms. Document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path. This proposal does not specify any changes to the BGP protocol definition. It does not require upgrades to provider edge or core routers nor does it need network wide upgrades. | ||||||||||||||||
| draft-ietf-grow-ops-reqs-for-bgp-error-handling-03.txt | |||||||||||||||||
| Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 | |||||||||||||||||
|
BGP-4 is utilised as a key intra- and inter-Autonomous System routing protocol in modern IP networks. The failure modes as defined by the original protocol standards are based on a number of assumptions around the impact of session failure. Numerous incidents both in the global Internet routing table and within Service Provider networks have been caused by strict handling of a single invalid UPDATE message causing large-scale failures in one or more Autonomous Systems. This memo describes the current use of BGP-4 within Service Provider networks, and outlines a set of requirements for further work to enhance the mechanisms available to a BGP-4 implementation when erroneous data is detected. Whilst this document does not provide specification of any standard, it is intended as an overview of a set of enhancements to BGP-4 to improve the protocol's robustness to suit its current deployment. | ||||||||||||||||
| draft-ietf-grow-private-ip-sp-cores-04.txt | |||||||||||||||||
| Issues with Private IP Addressing in the Internet | |||||||||||||||||
|
The purpose of this document is to provide a discussion of the potential problems of using private, RFC1918, or non-globally- routable addressing within the core of an SP network. The discussion focuses on link addresses and to a small extent loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. | ||||||||||||||||
| draft-ietf-grow-simple-va-05.txt | |||||||||||||||||
| Simple Virtual Aggregation (S-VA) | |||||||||||||||||
|
The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB. Simple Virtual Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that allows any and all edge routers to shrink their RIB and FIB requirements substantially and therefore increase their useful lifetime. S-VA does not increase FIB requirements for core routers. S-VA is extremely easy to configure considerably more so than the various tricks done today to extend the life of edge routers. S-VA can be deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP. | ||||||||||||||||
| draft-ietf-grow-va-06.txt | |||||||||||||||||
| FIB Suppression with Virtual Aggregation | |||||||||||||||||
|
The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by not loading selected RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and all routers, easily by an order of magnitude with negligible increase in path length and load. FIB suppression can be deployed autonomously by an ISP without requiring cooperation between adjacent ISPs, and can co-exist with legacy routers in the ISP. | ||||||||||||||||
| draft-ietf-grow-va-auto-05.txt | |||||||||||||||||
| Auto-Configuration in Virtual Aggregation | |||||||||||||||||
|
Virtual Aggregation as specified in [I-D.ietf-grow-va] requires configuration of a static "VP-List" on all routers. The VP-List allows routers to know which prefixes may or may not be FIB- installed. This draft specified an optional method of determining this that requires far less configuration. Specifically, it requires the configuration of a "VP-Range" in ASBRs connected to transit and peer ISPs. A Non-transitive Extended Communities Attribute is used to convey to other routers that a given route can be FIB-suppressed. | ||||||||||||||||
| draft-ietf-hip-native-nat-traversal-02.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-hip-reload-instance-05.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-hip-rfc5201-bis-08.txt | |||||||||||||||||
| Host Identity Protocol Version 2 (HIPv2) | |||||||||||||||||
|
This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a SIGMA- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. | ||||||||||||||||
| draft-ietf-hokey-arch-design-11.txt | |||||||||||||||||
| Handover Keying (HOKEY) Architecture Design | |||||||||||||||||
|
The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748. This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group. | ||||||||||||||||
| draft-ietf-hokey-erp-aak-11.txt | |||||||||||||||||
| EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) | |||||||||||||||||
|
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or more candidate attachment points (CAPs) prior to handover. AAK uses the AAA infrastructure for key transport. This document specifies the extensions necessary to enable AAK support in ERP. | ||||||||||||||||
| draft-ietf-hokey-rfc5296bis-07.txt | |||||||||||||||||
| EAP Extensions for EAP Re-authentication Protocol (ERP) | |||||||||||||||||
|
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. This memo obsoletes RFC 5296. | ||||||||||||||||
| draft-ietf-homenet-arch-02.txt | |||||||||||||||||
| Home Networking Architecture for IPv6 | |||||||||||||||||
|
This text describes evolving networking technology within small residential home networks. The goal of this memo is to define the architecture for IPv6-based home networking and the associated principles, considerations and requirements. The text briefly highlights the implications of the introduction of IPv6 for home networking, discusses topology scenarios, 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. | ||||||||||||||||
| draft-ietf-httpbis-authscheme-registrations-03.txt | |||||||||||||||||
| Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations | |||||||||||||||||
|
This document registers Hypertext Transfer Protocol (HTTP) authentication schemes which have been defined in standards-track RFCs before the IANA HTTP Authentication Scheme Registry was established. | ||||||||||||||||
| draft-ietf-httpbis-method-registrations-07.txt | |||||||||||||||||
| Initial Hypertext Transfer Protocol (HTTP) Method Registrations | |||||||||||||||||
|
This document registers those Hypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. | ||||||||||||||||
| draft-ietf-httpbis-p1-messaging-19.txt | |||||||||||||||||
| HTTP/1.1,part 1: URIs,Connections,and Message Parsing | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to historic status, along with its predecessor RFC 2068. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations. This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817 (on using CONNECT for TLS upgrades) and moves them to historic status. | ||||||||||||||||
| draft-ietf-httpbis-p2-semantics-19.txt | |||||||||||||||||
| HTTP/1.1,part 2: Message Semantics | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields. | ||||||||||||||||
| draft-ietf-httpbis-p3-payload-19.txt | |||||||||||||||||
| HTTP/1.1,part 3: Message Payload and Content Negotiation | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation. | ||||||||||||||||
| draft-ietf-httpbis-p4-conditional-19.txt | |||||||||||||||||
| HTTP/1.1,part 4: Conditional Requests | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests. | ||||||||||||||||
| draft-ietf-httpbis-p5-range-19.txt | |||||||||||||||||
| HTTP/1.1,part 5: Range Requests and Partial Responses | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. | ||||||||||||||||
| draft-ietf-httpbis-p6-cache-19.txt | |||||||||||||||||
| HTTP/1.1,part 6: Caching | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. | ||||||||||||||||
| draft-ietf-httpbis-p7-auth-19.txt | |||||||||||||||||
| HTTP/1.1,part 7: Authentication | |||||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework. | ||||||||||||||||
| draft-ietf-hybi-websocket-multiplexing-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-hybi-websocket-perframe-compression-04.txt | |||||||||||||||||
| WebSocket Per-frame Compression | |||||||||||||||||
|
This specification defines a WebSocket extension that adds per-frame compression functionality to the WebSocket Protocol. It compresses the "Application data" portion of WebSocket data frames using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each frame. This specification provides one compression method available for the extension using DEFLATE. Please send feedback to the hybi@ietf.org mailing list. | ||||||||||||||||
| draft-ietf-idr-add-paths-guidelines-02.txt | |||||||||||||||||
| Best Practices for Advertisement of Multiple Paths in IBGP | |||||||||||||||||
|
Add-Paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. This provides a number of potential benefits, including reduced routing churn, faster convergence and better loadsharing. This document provides recommendations to implementers of Add-Paths so that network operators have the tools needed to address their specific applications and to manage the scalability impact of Add- Paths. A router implementing Add-Paths may learn many paths for a prefix and must decide which of these to advertise to peers. This document analyses different algorithms for making this selection and provides recommendations based on the target application. | ||||||||||||||||
| draft-ietf-idr-aigp-07.txt | |||||||||||||||||
| The Accumulated IGP Metric Attribute for BGP | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ietf-idr-as0-05.txt | |||||||||||||||||
| Codification of AS 0 processing. | |||||||||||||||||
|
This document updates RFC 4271 and proscribes the use of AS 0 in BGP OPEN and AS_PATH / AS4_PATH BGP attribute. | ||||||||||||||||
| draft-ietf-idr-as4octet-extcomm-generic-subtype-05.txt | |||||||||||||||||
| Generic Subtype for BGP Four-octet AS specific extended community | |||||||||||||||||
|
Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific BGP extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. | ||||||||||||||||
| draft-ietf-idr-best-external-05.txt | |||||||||||||||||
| Advertisement of the best external route in BGP | |||||||||||||||||
|
The current BGP-4 protocol specification [RFC4271] states that the selection process chooses the best path for a given route which is added to the Loc-Rib and advertised to all peers. Previous versions [RFC1771] of the specification defined a different rule for Internal BGP Updates. Given that Internal paths are not re- advertised to Internal peers, it was specified that the best of the external paths, as determined by the path selection tie breaking algorithm, would be advertised to Internal peers. This document extends that procedure to operate in environments where Route Reflection [RFC4456] or Confederations [RFC5065] are used and explains why advertising the additional routing information can improve convergence time without causing routing loops. Additional benefits include reduction of inter-domain churn and avoidance of permanent route oscillation. | ||||||||||||||||
| draft-ietf-idr-bgp-enhanced-route-refresh-01.txt | |||||||||||||||||
| Enhanced Route Refresh Capability for BGP-4 | |||||||||||||||||
|
In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate on-line, non-disruptive consistency validations of BGP routing updates. | ||||||||||||||||
| draft-ietf-idr-bgp-extended-messages-02.txt | |||||||||||||||||
| Extended Message support for BGP | |||||||||||||||||
|
The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This draft provides an extension to BGP to extend its current message size from 4096 octets to 65535 octets. | ||||||||||||||||
| draft-ietf-idr-bgp-gr-notification-00.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-idr-bgp-issues-06.txt | |||||||||||||||||
| Issues in Revising BGP-4 (RFC1771 to RFC4271) | |||||||||||||||||
|
This document records the issues discussed and the consensus reached in the Interdomain Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol as documented in RFC1771. The document focuses on the changes tracked from August 2002 when the last major push for revision began. The results of these efforts are encoded in RFC4271, which should be taken as normative for any of the issues that were discussed. The discussion here is intended to record how and why some of the changes to BGP were made. | ||||||||||||||||
| draft-ietf-idr-bgp-nh-cost-01.txt | |||||||||||||||||
| Carrying next-hop cost information in BGP | |||||||||||||||||
|
This document describes new BGP SAFI to exchange cost information to next-hops for the purpose of calculating best path from a peer perspective rather than local BGP speaker own perspective. | ||||||||||||||||
| draft-ietf-idr-bgp-optimal-route-reflection-02.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-idr-bgp4-mibv2-13.txt | |||||||||||||||||
| Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4),Second Version | |||||||||||||||||
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. | ||||||||||||||||
| draft-ietf-idr-custom-decision-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-idr-dynamic-cap-14.txt | |||||||||||||||||
| Dynamic Capability for BGP-4 | |||||||||||||||||
|
This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. | ||||||||||||||||
| draft-ietf-idr-enhanced-gr-00.txt | |||||||||||||||||
| Accelerated Routing Convergence for BGP Graceful Restart | |||||||||||||||||
|
In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. | ||||||||||||||||
| draft-ietf-idr-error-handling-01.txt | |||||||||||||||||
| Revised Error Handling for BGP UPDATE Messages | |||||||||||||||||
|
According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for several existing attributes. | ||||||||||||||||
| draft-ietf-idr-flow-spec-v6-03.txt | |||||||||||||||||
| Dissemination of Flow Specification Rules for IPv6 | |||||||||||||||||
|
Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. | ||||||||||||||||
| draft-ietf-idr-ix-bgp-route-server-00.txt | |||||||||||||||||
| Internet Exchange Route Server | |||||||||||||||||
|
This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more exterior BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. | ||||||||||||||||
| draft-ietf-idr-legacy-rtc-00.txt | |||||||||||||||||
| Automatic Route Target Filtering for legacy PEs | |||||||||||||||||
|
This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in RFC 4684. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace RFC 4684. | ||||||||||||||||
| draft-ietf-idr-link-bandwidth-04.txt | |||||||||||||||||
| BGP Link Bandwidth Extended Community | |||||||||||||||||
|
This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. | ||||||||||||||||
| draft-ietf-idr-operational-message-00.txt | |||||||||||||||||
| BGP OPERATIONAL Message | |||||||||||||||||
|
The BGP Version 4 routing protocol (RFC4271) is now used in many ways, crossing boundaries of administrative and technical responsibility. The protocol lacks an operational messaging plane which could be utilised to diagnose, troubleshoot and inform upon various conditions across these boundaries, securely, during protocol operation, without disruption. This document proposes a new BGP message type, the OPERATIONAL message, which can be used to effect such a messaging plane for use both between and within Autonomous Systems. | ||||||||||||||||
| draft-ietf-idr-reserved-extended-communities-03.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-idr-rfc4893bis-06.txt | |||||||||||||||||
| BGP Support for Four-octet AS Number Space | |||||||||||||||||
|
The Autonomous System (AS) number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893. | ||||||||||||||||
| draft-ietf-intarea-ipv4-id-update-04.txt | |||||||||||||||||
| Updated Specification of the IPv4 ID Field | |||||||||||||||||
|
The IPv4 Identification (ID) field enables fragmentation and reassembly, and as currently specified is required to be unique within the maximum lifetime for all datagrams with a given source/destination/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFC791, RFC1122, and RFC2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. | ||||||||||||||||
| draft-ietf-intarea-nat-reveal-analysis-02.txt | |||||||||||||||||
| Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments | |||||||||||||||||
|
This document analyzes a set of solution candidates to mitigate some of the issues encountered when address sharing is used. In particular, this document focuses on means to reveal a host identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier must be unique to each host under the same shared IP address. | ||||||||||||||||
| draft-ietf-ipfix-a9n-03.txt | |||||||||||||||||
| Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol | |||||||||||||||||
|
This document describes the export of aggregated Flow information using IPFIX. An Aggregated Flow is essentially an IPFIX Flow representing packets from multiple Original Flows sharing some set of common properties. The document describes Aggregated Flow export within the framework of IPFIX Mediators and defines an interoperable, implementation-independent method for Aggregated Flow export. | ||||||||||||||||
| draft-ietf-ipfix-configuration-model-10.txt | |||||||||||||||||
| Configuration Data Model for IPFIX and PSAMP | |||||||||||||||||
|
This document specifies a data model for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using the NETCONF protocol. The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML). | ||||||||||||||||
| draft-ietf-ipfix-flow-selection-tech-11.txt | |||||||||||||||||
| Flow Selection Techniques | |||||||||||||||||
|
Flow selection is the process of selecting a subset of flows from all observed flows. The Flow Selection Process may be located at an observation point, or on an IPFIX Mediator. Flow selection reduces the effort of post-processing flow data and transferring Flow Records. This document describes motivations for flow selection and presents flow selection techniques. It provides an information model for configuring flow selection techniques and discusses what information about a flow selection process should be exported. | ||||||||||||||||
| draft-ietf-ipfix-ie-doctors-02.txt | |||||||||||||||||
| Guidelines for Authors and Reviewers of IPFIX Information Elements | |||||||||||||||||
|
This document provides guidelines for the definition of IPFIX Information Elements for addition to the IANA IPFIX Information Element registry, in order to extend the applicability of the IPFIX protocol to new operations and management areas. | ||||||||||||||||
| draft-ietf-ipfix-information-model-rfc5102bis-01.txt | |||||||||||||||||
| Information Model for IP Flow Information eXport (IPFIX) | |||||||||||||||||
|
This memo defines an overview of the information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. | ||||||||||||||||
| draft-ietf-ipfix-mediation-protocol-00.txt | |||||||||||||||||
| Specification of the Protocol for IPFIX Mediation | |||||||||||||||||
|
This document specifies the IP Flow Information Export (IPFIX) protocol specific to Mediation. | ||||||||||||||||
| draft-ietf-ipfix-protocol-rfc5101bis-01.txt | |||||||||||||||||
| 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 an information 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. | ||||||||||||||||
| draft-ietf-ipfix-psamp-mib-04.txt | |||||||||||||||||
| Definitions of Managed Objects for Packet Sampling | |||||||||||||||||
|
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 extensions to the IPFIX SELECTOR MIB module [I-D.dkcm-ipfix-rfc5815bis]. For IPFIX implementations that use packet Sampling (PSAMP) techniques as described in [RFC5475], this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. | ||||||||||||||||
| draft-ietf-ipfix-rfc5815bis-03.txt | |||||||||||||||||
| Definitions of Managed Objects for IP Flow Information Export | |||||||||||||||||
|
This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. | ||||||||||||||||
| draft-ietf-ippm-reporting-metrics-09.txt | |||||||||||||||||
| Reporting IP Network Performance Metrics: Different Points of View | |||||||||||||||||
|
Consumers of IP network performance metrics have many different uses in mind. The memo provides "long-term" reporting considerations (e.g., hours, days, weeks or months, as opposed to 10 seconds), based on analysis of the two key audience points-of-view. It describes how the audience categories affect the selection of metric parameters and options when seeking info that serves their needs. | ||||||||||||||||
| draft-ietf-ippm-rt-loss-05.txt | |||||||||||||||||
| Round-trip Packet Loss Metrics | |||||||||||||||||
|
Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no metric specified according to the RFC 2330 framework. This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). | ||||||||||||||||
| draft-ietf-ippm-testplan-rfc2679-01.txt | |||||||||||||||||
| Test Plan and Results for Advancing RFC 2679 on the Standards Track | |||||||||||||||||
|
This memo proposes to advance a performance metric RFC along the standards track, specifically RFC 2679 on One-way Delay Metrics. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. | ||||||||||||||||
| draft-ietf-ippm-twamp-value-added-octets-03.txt | |||||||||||||||||
| Ericsson TWAMP Value-Added Octets | |||||||||||||||||
|
This memo describes an extension to the TWAMP test protocol for identifying and managing packet trains, which enables measuring capacity metrics like the available path capacity, tight section capacity and UDP delivery rate in the forward and reverse path directions. This memo contains the description of a working prototype. It does not represent a consensus of the IETF community. The IETF community is currently working on the problem statement and has not reached consensus on the preferred method for measuring capacity metrics. | ||||||||||||||||
| draft-ietf-ipsecme-p2p-vpn-problem-01.txt | |||||||||||||||||
| Auto Discovery VPN Problem Statement | |||||||||||||||||
|
This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of end points change or the end points may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution is chartered to address these requirements. | ||||||||||||||||
| draft-ietf-iri-3987bis-11.txt | |||||||||||||||||
| Internationalized Resource Identifiers (IRIs) | |||||||||||||||||
|
This document defines the Internationalized Resource Identifier (IRI) protocol element, as an extension of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). Grammar and processing rules are given for IRIs and related syntactic forms. Defining IRI as a new protocol element (rather than updating or extending the definition of URI) allows independent orderly transitions: protocols and languages that use URIs must explicitly choose to allow IRIs. Guidelines are provided for the use and deployment of IRIs and related protocol elements when revising protocols, formats, and software components that currently deal only with URIs. This document is part of a set of documents intended to replace RFC 3987. | ||||||||||||||||
| draft-ietf-iri-4395bis-irireg-04.txt | |||||||||||||||||
| Guidelines and Registration Procedures for New URI/IRI Schemes | |||||||||||||||||
|
This document updates the guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes, and extends the registry and guidelines to apply when the schemes are used with Internationalized Resource Identifiers (IRIs). It also updates the process and IANA registry for URI/IRI schemes. It obsoletes RFC 4395. | ||||||||||||||||
| draft-ietf-iri-bidi-guidelines-02.txt | |||||||||||||||||
| Guidelines for Internationalized Resource Identifiers with Bi- directional Characters (Bidi IRIs) | |||||||||||||||||
|
This specification gives guidelines for selection, use, and presentation of International Resource Identifiers (IRIs) which include characters with inherent right-to-left (rtl) writing direction. | ||||||||||||||||
| draft-ietf-iri-comparison-01.txt | |||||||||||||||||
| Equivalence and Canonicalization of Internationalized Resource Identifiers (IRIs) | |||||||||||||||||
|
Internationalized Resource Identifiers (IRIs) are unicode strings used to identify resources on the Internet. Applications that use IRIs often define a means of comparing two IRIs to determine when two IRIs are equivalent for the purpose of that application. Some applications also define a method for 'canonicalizing' or 'normalizing' an IRI -- translating one IRI into another which is equivalent under the comparison method used. This document gives guidelines and best practices for defining and using IRI comparison, equivalence, normalization and canonicalization methods. | ||||||||||||||||
| draft-ietf-isis-genapp-04.txt | |||||||||||||||||
| Advertising Generic Information in IS-IS | |||||||||||||||||
|
This draft describes the manner in which generic application information (i.e. information not directly related to the operation of the IS-IS protocol) should be advertised in IS-IS LSPs and defines guidelines which should be used when flooding such information. | ||||||||||||||||
| draft-ietf-isis-mi-06.txt | |||||||||||||||||
| IS-IS Multi-Instance | |||||||||||||||||
|
This draft describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System To Intermediate System (IS-IS) routing protocol instances. Multiple instances allow the isolation of resources associated with each instance. Routers will form instance specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type Length Value (TLV) identifying the instance and the topology(ies) to which the PDU belongs. | ||||||||||||||||
| draft-ietf-jose-json-web-algorithms-02.txt | |||||||||||||||||
| JSON Web Algorithms (JWA) | |||||||||||||||||
|
The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS) and JSON Web Encryption (JWE) specifications. | ||||||||||||||||
| draft-ietf-jose-json-web-encryption-02.txt | |||||||||||||||||
| JSON Web Encryption (JWE) | |||||||||||||||||
|
JSON Web Encryption (JWE) is a means of representing encrypted content using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. | ||||||||||||||||
| draft-ietf-jose-json-web-key-02.txt | |||||||||||||||||
| JSON Web Key (JWK) | |||||||||||||||||
|
A JSON Web Key (JWK) is a JSON data structure that represents a public 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 used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. | ||||||||||||||||
| draft-ietf-jose-json-web-signature-02.txt | |||||||||||||||||
| JSON Web Signature (JWS) | |||||||||||||||||
|
JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. | ||||||||||||||||
| draft-ietf-karp-ops-model-02.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-karp-ospf-analysis-03.txt | |||||||||||||||||
| Analysis of OSPF Security According to KARP Design Guide | |||||||||||||||||
|
This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide. | ||||||||||||||||
| draft-ietf-karp-routing-tcp-analysis-01.txt | |||||||||||||||||
| Analysis of BGP,LDP,PCEP,and MSDP Security According to KARP Design Guide | |||||||||||||||||
|
This document analyzes BGP, LDP, PCEP and MSDP according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines [RFC6518]. | ||||||||||||||||
| draft-ietf-karp-threats-reqs-05.txt | |||||||||||||||||
| Keying and Authentication for Routing Protocols (KARP) Overview,Threats,and Requirements | |||||||||||||||||
|
Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and a set of requirements for KARP design teams to follow. RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" is a companion to this document; KARP design teams will use them together to review and overhaul routing protocols. These two documents reflect the input of both the IETF's Security Area and Routing Area in order to form a mutually agreeable work plan. This document has three main parts. The first part provides an overview of the KARP effort. The second part lists the threats from RFC 4593, Generic Threats To Routing Protocols, that are in scope for attacks against routing protocols' transport systems, including any mechanisms built into the routing protocols themselves, which accomplish packet authentication. The third part enumerates the requirements that routing protocol specifications must meet when addressing those threats for RFC 6518's "Work Phase 1", the update to a routing protocol's existing transport security. | ||||||||||||||||
| draft-ietf-kitten-gssapi-naming-exts-14.txt | |||||||||||||||||
| GSS-API Naming Extensions | |||||||||||||||||
|
The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. | ||||||||||||||||
| draft-ietf-kitten-sasl-openid-08.txt | |||||||||||||||||
| A SASL & GSS-API Mechanism for OpenID | |||||||||||||||||
|
OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. | ||||||||||||||||
| draft-ietf-kitten-sasl-saml-ec-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-krb-wg-camellia-cts-01.txt | |||||||||||||||||
| Camellia Encryption for Kerberos 5 | |||||||||||||||||
|
This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC 3961. The new types use the Camellia block cipher in CBC-mode with ciphertext stealing and the CMAC algorithm for integrity protection. | ||||||||||||||||
| draft-ietf-krb-wg-cammac-02.txt | |||||||||||||||||
| Container Authenticated by Multiple MACs | |||||||||||||||||
|
Abstract: This document proposes a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple MACs or signatures on the contained Authorization Data elements. | ||||||||||||||||
| draft-ietf-krb-wg-des-die-die-die-04.txt | |||||||||||||||||
| Deprecate DES,RC4-HMAC-EXP,and other weak cryptographic algorithms in Kerberos | |||||||||||||||||
|
The Kerberos 5 network authentication protocol, originally specified in RFC1510, can use the Data Encryption Standard (DES) for encryption. Almost 30 years after first publishing DES, the National Institute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure. By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average. DES is long past its sell-by date. Accordingly, this document updates RFC1964, RFC4120, RFC4121, and RFC4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos. Because RFC1510 (obsoleted by RFC4120) supports only DES, this document reclassifies RFC1510 as Historic. | ||||||||||||||||
| draft-ietf-krb-wg-kdc-model-11.txt | |||||||||||||||||
| An information model for Kerberos version 5 | |||||||||||||||||
|
This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a kerberos 5 KDC. This document describes the services exposed by an administrative interface to a KDC. | ||||||||||||||||
| draft-ietf-krb-wg-kerberos-referrals-14.txt | |||||||||||||||||
| Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals | |||||||||||||||||
|
The memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm TGT to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120. | ||||||||||||||||
| draft-ietf-krb-wg-pad-01.txt | |||||||||||||||||
| POSIX Authorization Data | |||||||||||||||||
|
This document proposes a Kerberos Authorization Data element containing user and group directory information similar to that provided by RFC 2307, typically used by POSIX and POSIX-like systems in the course of login type activities. | ||||||||||||||||
| draft-ietf-krb-wg-pkinit-alg-agility-06.txt | |||||||||||||||||
| PKINIT Algorithm Agility | |||||||||||||||||
|
This document updates PKINIT, as defined in RFC 4556, to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. | ||||||||||||||||
| draft-ietf-l2vpn-arp-mediation-19.txt | |||||||||||||||||
| ARP Mediation for IP Interworking of Layer 2 VPN | |||||||||||||||||
|
The Virtual Private Wire Service (VPWS) [RFC4664] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. | ||||||||||||||||
| draft-ietf-l2vpn-etree-frwk-00.txt | |||||||||||||||||
| A Framework for E-Tree Service over MPLS Network | |||||||||||||||||
|
This document proposes a solution framework for supporting Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) services over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network. | ||||||||||||||||
| draft-ietf-l2vpn-etree-reqt-01.txt | |||||||||||||||||
| Requirements for MEF E-Tree Support in VPLS | |||||||||||||||||
|
This document provides functional requirements for Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) support in Virtual Private LAN Service (VPLS). It is intended that potential solutions will use these requirements as guidelines. | ||||||||||||||||
| draft-ietf-l2vpn-evpn-00.txt | |||||||||||||||||
| BGP MPLS Based Ethernet VPN | |||||||||||||||||
|
This document describes procedures for BGP MPLS based Ethernet VPNs (E-VPN). | ||||||||||||||||
| draft-ietf-l2vpn-evpn-req-00.txt | |||||||||||||||||
| Requirements for Ethernet VPN (E-VPN) | |||||||||||||||||
|
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 VPLS solution. In particular, multi- homing with all-active forwarding is not supported and there's no existing solution to leverage 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. | ||||||||||||||||
| draft-ietf-l2vpn-ldp-vpls-broadcast-exten-03.txt | |||||||||||||||||
| Extension to LDP-VPLS for Ethernet Broadcast and Multicast | |||||||||||||||||
|
This document proposes a simple extension to LDP-VPLS to improve bandwidth efficiency for Ethernet broadcast/multicast traffic within a carrier's network. It makes use of unidirectional point-to-multipoint PseudoWires to minimise payload frame duplication on physical links. | ||||||||||||||||
| draft-ietf-l2vpn-pbb-evpn-02.txt | |||||||||||||||||
| PBB E-VPN | |||||||||||||||||
|
This document discusses how Ethernet Provider Backbone Bridging [802.1ah] can be combined with E-VPN in order to reduce the number of BGP MAC advertisement routes by aggregating Customer/Client MAC (C- MAC) addresses via Provider Backbone MAC address (B-MAC), provide client MAC address mobility using C-MAC aggregation and B-MAC sub- netting, confine the scope of C-MAC learning to only active flows, offer per site policies and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN. Conventions | ||||||||||||||||
| draft-ietf-l2vpn-vpls-ldp-mac-opt-06.txt | |||||||||||||||||
| LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS | |||||||||||||||||
|
[RFC4762] describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology change. This document defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to [RFC4762] MAC Withdrawal procedures are specified to provide optimized MAC flushing for the PBB-VPLS specified in [PBB-VPLS Model]. | ||||||||||||||||
| draft-ietf-l2vpn-vpls-mcast-10.txt | |||||||||||||||||
| Multicast in VPLS | |||||||||||||||||
|
This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSes are also described. | ||||||||||||||||
| draft-ietf-l2vpn-vpws-iw-oam-03.txt | |||||||||||||||||
| OAM Procedures for VPWS Interworking | |||||||||||||||||
|
This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). | ||||||||||||||||
| draft-ietf-l3vpn-mvpn-bidir-01.txt | |||||||||||||||||
| MVPN: Using Bidirectional P-Tunnels | |||||||||||||||||
|
The documents specifying multicast support for BGP/MPLS IP VPNs allow customer multicast data to be transported through a service provider's network through a set multicast tunnels. Such tunnels are advertised by BGP in a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel Attribute". The base specifications allow the PMSI Tunnel Attribute to advertise bidirectional multicast distribution trees as "PMSI Tunnels"; however, those documents do not provide all the necessary details for using those tunnels. These details are provided in this document. This document also specifies the procedures for assigning customer multicast flows to specific bidirectional PMSI tunnels. | ||||||||||||||||
| draft-ietf-l3vpn-mvpn-mib-00.txt | |||||||||||||||||
| MPLS/BGP Layer 3 VPN Multicast Management Information Base | |||||||||||||||||
|
This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor multicast in MPLS/BGP-based Layer-3 VPN (MVPN) on an MVPN router. | ||||||||||||||||
| draft-ietf-l3vpn-ospfv3-pece-11.txt | |||||||||||||||||
| OSPFv3 as a PE-CE routing protocol | |||||||||||||||||
|
Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs, however only Open Shortest Path First protocol version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. | ||||||||||||||||
| draft-ietf-l3vpn-virtual-hub-01.txt | |||||||||||||||||
| Virtual Hub-and-Spoke in BGP/MPLS VPNs | |||||||||||||||||
|
With BGP/MPLS VPNs any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Furthermore, when Provider Edge routers use ingress replication to carry multicast traffic of VPN customers, the approach described in this document could allow to reduce bandwidth inefficiency associated with ingress replication, and to redistribute the replication load among Provider Edge routers. | ||||||||||||||||
| draft-ietf-ledbat-congestion-09.txt | |||||||||||||||||
| Low Extra Delay Background Transport (LEDBAT) | |||||||||||||||||
|
LEDBAT is an experimental delay-based congestion control algorithm that attempts to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on the path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications; it is designed to be no more aggressive than TCP congestion control and to yield in the presence of any competing flows when latency builds, thus limiting interference with the network performance of the competing flows. | ||||||||||||||||
| draft-ietf-lisp-23.txt | |||||||||||||||||
| Locator/ID Separation Protocol (LISP) | |||||||||||||||||
|
This draft describes a network layer based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. | ||||||||||||||||
| draft-ietf-lisp-alt-10.txt | |||||||||||||||||
| LISP Alternative Topology (LISP+ALT) | |||||||||||||||||
|
This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). | ||||||||||||||||
| draft-ietf-lisp-deployment-03.txt | |||||||||||||||||
| LISP Network Element Deployment Considerations | |||||||||||||||||
|
This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). | ||||||||||||||||
| draft-ietf-lisp-eid-block-02.txt | |||||||||||||||||
| LISP EID Block | |||||||||||||||||
|
This is a direction to IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. | ||||||||||||||||
| draft-ietf-lisp-interworking-06.txt | |||||||||||||||||
| Interworking LISP with IPv4 and IPv6 | |||||||||||||||||
|
This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites (which may be using either IPv4, IPv6, or both) but which are not running LISP. A fundamental property of LISP speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Routers (Proxy-ITRs) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. Second the document adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. | ||||||||||||||||
| draft-ietf-lisp-lig-06.txt | |||||||||||||||||
| LISP Internet Groper (LIG) | |||||||||||||||||
|
A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works. | ||||||||||||||||
| draft-ietf-lisp-map-versioning-09.txt | |||||||||||||||||
| LISP Map-Versioning | |||||||||||||||||
|
This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. | ||||||||||||||||
| draft-ietf-lisp-mib-03.txt | |||||||||||||||||
| LISP MIB | |||||||||||||||||
|
This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. | ||||||||||||||||
| draft-ietf-lisp-ms-16.txt | |||||||||||||||||
| LISP Map Server Interface | |||||||||||||||||
|
This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. | ||||||||||||||||
| draft-ietf-lisp-multicast-14.txt | |||||||||||||||||
| LISP for Multicast Environments | |||||||||||||||||
|
This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. | ||||||||||||||||
| draft-ietf-lisp-sec-02.txt | |||||||||||||||||
| LISP-Security (LISP-SEC) | |||||||||||||||||
|
This memo specifies LISP-SEC, a set of security mechanisms that provide origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. | ||||||||||||||||
| draft-ietf-lisp-threats-01.txt | |||||||||||||||||
| LISP Threats Analysis | |||||||||||||||||
|
This document analyzes the threats against the security of the Locator/Identifier Separation Protocol and proposes a set of recommendations to mitigate some of the identified security risks. | ||||||||||||||||
| draft-ietf-manet-dlep-02.txt | |||||||||||||||||
| Dynamic Link Exchange Protocol (DLEP) | |||||||||||||||||
|
When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. | ||||||||||||||||
| draft-ietf-manet-dymo-22.txt | |||||||||||||||||
| Dynamic MANET On-demand (AODVv2) Routing | |||||||||||||||||
|
The Dynamic MANET On-demand (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. | ||||||||||||||||
| draft-ietf-manet-nhdp-mib-13.txt | |||||||||||||||||
| Definition of Managed Objects for the Neighborhood Discovery Protocol | |||||||||||||||||
|
This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. | ||||||||||||||||
| draft-ietf-manet-nhdp-sec-01.txt | |||||||||||||||||
| Using Integrity Check Values and Timestamps in NHDP | |||||||||||||||||
|
This document specifies a security extension to the MANET Neighbor Discovery Protocol (NHDP). The extension introduces the use of Integrity Check Values (ICVs) and Timestamps in HELLO messages in order to counter a selection of security threats to NHDP. | ||||||||||||||||
| draft-ietf-manet-nhdp-sec-threats-00.txt | |||||||||||||||||
| Security Threats for NHDP | |||||||||||||||||
|
This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. | ||||||||||||||||
| draft-ietf-manet-olsrv2-15.txt | |||||||||||||||||
| The Optimized Link State Routing Protocol version 2 | |||||||||||||||||
|
This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). | ||||||||||||||||
| draft-ietf-manet-olsrv2-mib-04.txt | |||||||||||||||||
| 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 state information, performance metrics, and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues of the routing protocol. Different levels of compliance allow implementers to use smaller subsets of all defined objects, allowing for this MIB module to be deployed on more constrained routers. | ||||||||||||||||
| draft-ietf-manet-report-mib-02.txt | |||||||||||||||||
| Definition of Managed Objects for Performance Reporting | |||||||||||||||||
|
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 objects for configuring autonomous report generation on any device that supports MIBs containing counter and gauge objects for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected asynchronously by the management station. Further, this REPORT-SAMPLED-MIB can be configured in a proxy configuration where the report generation is performed on a device in close network proximity to the device containing the referenced counter objects. Hence, this capability allows network operators to reduce the SNMP polling traffic burden on Mobile Ad-Hoc and Disruption Tolerant Networks which is typical of SNMP performance management applications. | ||||||||||||||||
| draft-ietf-marf-as-16.txt | |||||||||||||||||
| Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) | |||||||||||||||||
|
RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This Applicability Statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. | ||||||||||||||||
| draft-ietf-marf-dkim-reporting-16.txt | |||||||||||||||||
| Extensions to DKIM for Failure Reporting | |||||||||||||||||
|
This document presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. | ||||||||||||||||
| draft-ietf-marf-spf-reporting-10.txt | |||||||||||||||||
| SPF Authentication Failure Reporting using the Abuse Report Format | |||||||||||||||||
|
This memo presents extensions to the Abuse Reporting Format (ARF), and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. This memo updates RFC4408 by providing an IANA registry for SPF modifiers. | ||||||||||||||||
| draft-ietf-mboned-64-multicast-address-format-02.txt | |||||||||||||||||
| IPv6 Multicast Address Format With Embedded IPv4 Multicast Address | |||||||||||||||||
|
This document specifies an extension to the IPv6 multicast addressing architecture to be used in the context of IPv4-IPv6 interconnection. In particular, this document defines an address format for IPv4- embedded IPv6 multicast addresses. This address format can be used for IPv4-IPv6 translation or encapsulation schemes. This document updates RFC4291. | ||||||||||||||||
| draft-ietf-mboned-auto-multicast-13.txt | |||||||||||||||||
| Automatic Multicast Tunneling | |||||||||||||||||
|
This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality. The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure. | ||||||||||||||||
| draft-ietf-mboned-mcaddrdoc-04.txt | |||||||||||||||||
| Multicast Addresses for Documentation | |||||||||||||||||
|
This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. | ||||||||||||||||
| draft-ietf-mboned-v4v6-mcast-ps-00.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-mediactrl-call-flows-08.txt | |||||||||||||||||
| Media Control Channel Framework (CFW) Call Flow Examples | |||||||||||||||||
|
This document provides a list of typical Media Control Channel Framework [RFC6230] 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. | ||||||||||||||||
| draft-ietf-mediactrl-mrb-12.txt | |||||||||||||||||
| Media Resource Brokering | |||||||||||||||||
|
The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. | ||||||||||||||||
| draft-ietf-mext-mip6-tls-05.txt | |||||||||||||||||
| Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication | |||||||||||||||||
|
Mobile IPv6 signaling between a mobile node and its home agent is secured using IPsec. The security association between a mobile node and the home agent is established using IKEv1 or IKEv2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/ IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the mobile node and home agent. | ||||||||||||||||
| draft-ietf-mif-api-extension-00.txt | |||||||||||||||||
| MIF API consideration | |||||||||||||||||
|
This document describes an abstract API that provides the minimal functionality required for a program to communicate effectively with peers and services on the network while running on a host that has more than one active network interface. This API is abstract: we describe the functionality that must be provided, not the bindings that should be used to provide that functionality. The functionality described here provides the building blocks from which higher-level APIs might be built, and is not intended to be used directly by typical applications. | ||||||||||||||||
| draft-ietf-mif-dhcpv6-route-option-04.txt | |||||||||||||||||
| DHCPv6 Route Options | |||||||||||||||||
|
This document describes DHCPv6 Route Options for provisioning IPv6 routes on DHCPv6 client nodes. This is expected to improve the ability of an operator to configure and influence a nodes' ability to pick an appropriate route to a destination when this node is multi- homed and where other means of route configuration may be impractical. | ||||||||||||||||
| draft-ietf-mif-dns-server-selection-09.txt | |||||||||||||||||
| Improved Recursive DNS Server Selection for Multi-Interfaced Nodes | |||||||||||||||||
|
A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions. | ||||||||||||||||
| draft-ietf-mile-grc-exchange-00.txt | |||||||||||||||||
| GRC Report Exchange | |||||||||||||||||
|
Governance, risk, and compliance (GRC) programs provide oversight (governance) of risks and compliance initiatives within an organization. GRC reports are increasingly provided in an XML format. This specification defines a common method to securely transport GRC and other XML reports. The defined messaging capability provides policy options and markings in an XML schema, options for confidentiality at the document/report level, and security for the end-to-end communication. XML reports may be shared between service providers and clients, enterprises, or within enterprises. Reports may also be exchanged for official purposes such as business report filings, compliance report filings, and the handling of legal incidents (eWarrant, eDiscovery, etc.) This work is a generalized format derived from the secure exchange of incident information defined by RFC6545, Real-time Inter-network Defense (RID). | ||||||||||||||||
| draft-ietf-mile-iodef-xmlreg-01.txt | |||||||||||||||||
| Expert Review for IODEF Extensions in IANA XML Registry | |||||||||||||||||
|
This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to IODEF. | ||||||||||||||||
| draft-ietf-mile-sci-04.txt | |||||||||||||||||
| IODEF-extension to support structured cybersecurity information | |||||||||||||||||
|
This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched cybersecurity information exchange among cybersecurity entities. It provides the capability of embedding structured information, such as identifier- and XML-based information. | ||||||||||||||||
| draft-ietf-mile-template-04.txt | |||||||||||||||||
| Guidelines for Defining Extensions to IODEF | |||||||||||||||||
|
This document provides guidelines for extensions to IODEF [RFC5070] for exchange of incident management data, and contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. | ||||||||||||||||
| draft-ietf-mip4-multiple-tunnel-support-03.txt | |||||||||||||||||
| Flow Binding Support for Mobile IPv4 | |||||||||||||||||
|
This specification defines extensions to Mobile IPv4 protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple Mobile IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build an higher aggregated data pipe with the home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate flow policies for binding individual traffic flows with the registered care-of addresses. | ||||||||||||||||
| draft-ietf-mip4-nemov4-dynamic-06.txt | |||||||||||||||||
| Dynamic Prefix Allocation for NEMOv4 | |||||||||||||||||
|
The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. | ||||||||||||||||
| draft-ietf-mmusic-media-loopback-18.txt | |||||||||||||||||
| An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback | |||||||||||||||||
|
The wide deployment of Voice over IP (VoIP), Text and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes, which enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. | ||||||||||||||||
| draft-ietf-mmusic-media-path-middleboxes-04.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-mmusic-rfc2326bis-29.txt | |||||||||||||||||
| Real Time Streaming Protocol 2.0 (RTSP) | |||||||||||||||||
|
This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). | ||||||||||||||||
| draft-ietf-mmusic-rfc4566bis-05.txt | |||||||||||||||||
| SDP: Session Description Protocol | |||||||||||||||||
|
This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. | ||||||||||||||||
| draft-ietf-mmusic-rtsp-nat-12.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-mmusic-rtsp-nat-evaluation-05.txt | |||||||||||||||||
| The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) | |||||||||||||||||
|
This document describes several Network Address Translator (NAT) traversal techniques that was considered to be used by 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 disussions 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 standardized in the MMUSIC WG. | ||||||||||||||||
| draft-ietf-mmusic-sctp-sdp-01.txt | |||||||||||||||||
| Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) | |||||||||||||||||
|
SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers for SDP. | ||||||||||||||||
| draft-ietf-mmusic-sdp-bundle-negotiation-00.txt | |||||||||||||||||
| Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers | |||||||||||||||||
|
This specification defines a new SDP Grouping Framework 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). | ||||||||||||||||
| draft-ietf-mmusic-sdp-cs-11.txt | |||||||||||||||||
| Session Description Protocol (SDP) Extension For Setting Up 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). | ||||||||||||||||
| draft-ietf-mmusic-sdp-media-capabilities-13.txt | |||||||||||||||||
| SDP Media Capabilities Negotiation | |||||||||||||||||
|
Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. | ||||||||||||||||
| draft-ietf-mmusic-sdp-miscellaneous-caps-00.txt | |||||||||||||||||
| Miscellanoues 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). | ||||||||||||||||
| draft-ietf-mmusic-traffic-class-for-sdp-01.txt | |||||||||||||||||
| The Session Description Protocol (SDP) 'trafficclass' Attribute | |||||||||||||||||
|
This document proposes a new Session Description Protocol (SDP) attribute to identify the traffic class a session is requesting in its offer/answer exchange. | ||||||||||||||||
| draft-ietf-mpls-entropy-label-03.txt | |||||||||||||||||
| The Use of Entropy Labels in MPLS Forwarding | |||||||||||||||||
|
Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. | ||||||||||||||||
| draft-ietf-mpls-gach-adv-02.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-mpls-ldp-dod-01.txt | |||||||||||||||||
| LDP Downstream-on-Demand in Seamless MPLS | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ietf-mpls-ldp-gtsm-06.txt | |||||||||||||||||
| The Generalized TTL Security Mechanism (GTSM) for Label Distribution Protocol (LDP) | |||||||||||||||||
|
The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control-plane from CPU utilization based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP). This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. | ||||||||||||||||
| draft-ietf-mpls-ldp-ip-pw-capability-01.txt | |||||||||||||||||
| LDP IP and PW Capability | |||||||||||||||||
|
Currently, no LDP capability is exchanged for LDP applications like IP label switching and L2VPN/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 may be established for some other applications like ICCP. This document proposes a solution by which an LDP speaker announces its disinterest or non- support for IP label switching or L2VPN/PW application, hence disabling corresponding application state exchange over the established LDP session. | ||||||||||||||||
| draft-ietf-mpls-ldp-ipv6-06.txt | |||||||||||||||||
| Updates to LDP for IPv6 | |||||||||||||||||
|
The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. | ||||||||||||||||
| draft-ietf-mpls-ldp-multi-topology-03.txt | |||||||||||||||||
| 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 describes the LDP protocol extensions required to support MT routing in an MPLS environment. | ||||||||||||||||
| draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-04.txt | |||||||||||||||||
| Configuration of Pro-Active Operations,Administration,and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping | |||||||||||||||||
|
This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP Ping protocol This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication 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. | ||||||||||||||||
| draft-ietf-mpls-lsp-ping-ttl-tlv-02.txt | |||||||||||||||||
| Definition of Time-to-Live TLV for LSP-Ping Mechanisms | |||||||||||||||||
|
LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) from any node on the path of the MS-PW. This document defines a TLV to address this shortcoming. | ||||||||||||||||
| draft-ietf-mpls-mldp-in-band-signaling-05.txt | |||||||||||||||||
| Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint- to-Multipoint Label Switched Paths | |||||||||||||||||
|
Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), needs to pass through an MPLS domain in which Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- Multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. | ||||||||||||||||
| draft-ietf-mpls-seamless-mcast-03.txt | |||||||||||||||||
| 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 IP multicast over MPLS. | ||||||||||||||||
| draft-ietf-mpls-seamless-mpls-01.txt | |||||||||||||||||
| Seamless MPLS Architecture | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ietf-mpls-tp-ethernet-addressing-01.txt | |||||||||||||||||
| MPLS-TP Next-Hop Ethernet Addressing | |||||||||||||||||
|
The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication 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. | ||||||||||||||||
| draft-ietf-mpls-tp-itu-t-identifiers-03.txt | |||||||||||||||||
| MPLS-TP Identifiers Following ITU-T Conventions | |||||||||||||||||
|
This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. | ||||||||||||||||
| draft-ietf-mpls-tp-mib-management-overview-08.txt | |||||||||||||||||
| Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview | |||||||||||||||||
|
A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. | ||||||||||||||||
| draft-ietf-mpls-tp-mip-mep-map-01.txt | |||||||||||||||||
| Handling MPLS-TP OAM Packets Targeted at Internal MIPs | |||||||||||||||||
|
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 describes a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces, forwarded correctly through the "switch fabric", and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication 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. | ||||||||||||||||
| draft-ietf-mpls-tp-oam-analysis-09.txt | |||||||||||||||||
| An Overview of the OAM Tool Set for MPLS based Transport Networks | |||||||||||||||||
|
This document provides an overview of the OAM toolset for MPLS based Transport Networks (MPLS-TP). The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. | ||||||||||||||||
| draft-ietf-mpls-tp-ring-protection-02.txt | |||||||||||||||||
| Applicability of MPLS-TP Linear Protection for Ring Topologies | |||||||||||||||||
|
This document presents an applicability statement to address the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) on multiple layers. The MPLS-TP Requirements document specifies specific criteria for justification of dedicated protection mechanism for particular topologies, including optimizing the number of OAM entities needed, minimizing the number of labels for protection paths, minimizing the number of recovery elements in the network, and minimizing the number of control and management transactions necessary. The document proposes a methodology for ring protection based on existing MPLS-TP survivability mechanisms, specifically those defined in MPLS-TP Linear Protection, without the need for specification of new constructs or protocols. 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. | ||||||||||||||||
| draft-ietf-mpls-tp-rosetta-stone-05.txt | |||||||||||||||||
| A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations. | |||||||||||||||||
|
MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. | ||||||||||||||||
| draft-ietf-mpls-tp-security-framework-03.txt | |||||||||||||||||
| MPLS-TP Security Framework | |||||||||||||||||
|
This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new OAM capabilities, a transport- oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats, security requirements for MPLS-TP, and mitigation procedures for MPLS-TP networks and MPLS-TP interconnection to other MPLS and GMPLS networks. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication 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. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] | ||||||||||||||||
| draft-ietf-mpls-tp-te-mib-03.txt | |||||||||||||||||
| MPLS-TP Traffic Engineering (TE) 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 managed objects of Tunnels, Identifiers, Label Switch Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). | ||||||||||||||||
| draft-ietf-mpls-tp-temporal-hitless-psm-00.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-mpls-tp-use-cases-and-design-01.txt | |||||||||||||||||
| MPLS-TP Applicability; Use Cases and Design | |||||||||||||||||
|
This document provides applicability, use case studies and network design considerations for Multiprotocol Label Switching Transport profile (MPLS-TP). In the recent years, MPLS-TP has emerged as the technology of choice for the new generation of packet transport. Many service providers (SPs) are working to replace the legacy transport technologies, e.g. SONET/SDH, TDM, and ATM technologies, with MPLS-TP for packet transport, in order to achieve higher efficiency, lower operational cost, while maintaining transport characteristics. The use cases for MPLS-TP include Metro Ethernet access and aggregation, Mobile backhaul, and packet optical transport. The design considerations discussed in this documents ranging from operational experience; standards compliance; technology maturity; end-to-end forwarding and OAM consistency; compatibility with IP/MPLS networks; multi-vendor interoperability; and optimization vs. simplicity design trade off discussion. The general design principle is to provide reliable, manageable, and scalable transport solutions. | ||||||||||||||||
| draft-ietf-mptcp-api-05.txt | |||||||||||||||||
| MPTCP Application Interface Considerations | |||||||||||||||||
|
Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface which is a simple extension of TCP's interface for MPTCP-aware applications. | ||||||||||||||||
| draft-ietf-mptcp-multiaddressed-08.txt | |||||||||||||||||
| TCP Extensions for Multipath Operation with Multiple Addresses | |||||||||||||||||
|
TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. | ||||||||||||||||
| draft-ietf-multimob-fast-handover-00.txt | |||||||||||||||||
| PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL) | |||||||||||||||||
|
This document specifies a multicast handover optimization mechanism for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism is based on speeding up the acquisition of mobile nodes' active multicast subscriptions information by the mobile access gateways. To do that, extensions to the current Proxy Mobile IPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but also can be applied to other solutions envisioned as possible architectural evolutions of it. Furthermore, they are also independent of the role played by the mobile access gateway within the multicast network (either acting as multicast listener discovery proxy or multicast router). | ||||||||||||||||
| draft-ietf-multimob-pmipv6-ropt-00.txt | |||||||||||||||||
| Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 | |||||||||||||||||
|
The MULTIMOB group has specified a base solution to support IP multicasting in a PMIPv6 domain [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 deployments scenarios. | ||||||||||||||||
| draft-ietf-multimob-pmipv6-source-00.txt | |||||||||||||||||
| Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains | |||||||||||||||||
|
Multicast communication can be enabled in Proxy Mobile IPv6 domains via the Local Mobility Anchors by deploying MLD Proxy functions at Mobile Access Gateways, via a direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Mobile sources always remain agnostic of multicast mobility operations. | ||||||||||||||||
| draft-ietf-nea-asokan-00.txt | |||||||||||||||||
| NEA Asokan Attack Analysis | |||||||||||||||||
|
The Network Endpoint Assessment protocols are subject to a subtle forwarding attack that has become known as the NEA Asokan Attack. This document describes the attack and countermeasures that may be mounted. | ||||||||||||||||
| draft-ietf-nea-pt-eap-02.txt | |||||||||||||||||
| PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods | |||||||||||||||||
|
This document specifies PT-EAP, an EAP based Posture Transport (PT) protocol designed to be used only inside a TLS protected tunnel method. The document also describes the intended applicability of PT-EAP. | ||||||||||||||||
| draft-ietf-nea-pt-tls-04.txt | |||||||||||||||||
| PT-TLS: A TCP-based Posture Transport (PT) Protocol | |||||||||||||||||
|
This document specifies PT-TLS, a TCP-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. | ||||||||||||||||
| draft-ietf-netext-access-network-option-10.txt | |||||||||||||||||
| Access Network Identifier (ANI) Option for Proxy Mobile IPv6 | |||||||||||||||||
|
The local mobility anchor in a Proxy Mobile IPv6 domain is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. | ||||||||||||||||
| draft-ietf-netext-logical-interface-support-05.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-netext-pd-pmip-02.txt | |||||||||||||||||
| Prefix Delegation for Proxy Mobile IPv6 | |||||||||||||||||
|
Proxy Mobile IPv6 enables IP mobility for a host without requiring its participation in any mobility signaling, being the network responsible for managing IP mobility on behalf of the host. However, Proxy Mobile IPv6 does not support assigning a prefix to a router and managing its IP mobility. This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility using DHCPv6-based Prefix Delegation. | ||||||||||||||||
| draft-ietf-netext-pmip-lr-10.txt | |||||||||||||||||
| Localized Routing for Proxy Mobile IPv6 | |||||||||||||||||
|
Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, localized routing (LR) allows mobile nodes attached to the same or different mobile access gateways to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. | ||||||||||||||||
| draft-ietf-netext-pmipv6-flowmob-03.txt | |||||||||||||||||
| Proxy Mobile IPv6 Extensions to Support Flow Mobility | |||||||||||||||||
|
Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. However, the ability of movement of selected flows from one access technology to another is missing in the basic Proxy Mobile IPv6 protocol. This document describes extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. This document assumes that the mobile node implements the logical interface model, therefore allowing the support of traffic flows on different physical interfaces regardless of the assigned prefixes on these physical interfaces. | ||||||||||||||||
| draft-ietf-netext-pmipv6-sipto-option-04.txt | |||||||||||||||||
| IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 | |||||||||||||||||
|
This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. | ||||||||||||||||
| draft-ietf-netext-radius-pmip6-08.txt | |||||||||||||||||
| RADIUS Support for Proxy Mobile IPv6 | |||||||||||||||||
|
This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses Radius based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. | ||||||||||||||||
| draft-ietf-netext-rfc5149bis-00.txt | |||||||||||||||||
| Service Selection for Mobile IPv6 | |||||||||||||||||
|
In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents and local mobility agents to make a specific service selection for the mobility service subscription during the binding registration procedure. This specification updates RFC5213 and obsoletes RFC5149. | ||||||||||||||||
| draft-ietf-netext-wifi-epc-eap-attributes-00.txt | |||||||||||||||||
| EAP Attributes for WiFi - EPC Integration | |||||||||||||||||
|
With WiFi beginning to establishing itself as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access authentication protocol for trusted access networks. This IETF specification is required for mobile devices to access the 3GPP Evolved Packet Core (EPC) networks. This document defines a few new EAP attributes and procedures to provide the above-mentioned functions in trusted WiFi access networks. | ||||||||||||||||
| draft-ietf-netmod-iana-if-type-02.txt | |||||||||||||||||
| IANA Interface Type and Address Family YANG Modules | |||||||||||||||||
|
This document defines the initial versions of the iana-if-type and iana-afn-safi YANG modules. | ||||||||||||||||
| draft-ietf-netmod-interfaces-cfg-04.txt | |||||||||||||||||
| A YANG Data Model for Interface Configuration | |||||||||||||||||
|
This document defines a YANG data model for the configuration of network interfaces. It is expected that interface type specific configuration data models augment the generic interfaces data model defined in this document. | ||||||||||||||||
| draft-ietf-netmod-ip-cfg-03.txt | |||||||||||||||||
| A YANG Data Model for IP Configuration | |||||||||||||||||
|
This document defines a YANG data model for configuration of IP implementations. | ||||||||||||||||
| draft-ietf-netmod-routing-cfg-03.txt | |||||||||||||||||
| A YANG Data Model for Routing Configuration | |||||||||||||||||
|
This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring a routing subsystem. It is therefore expected that this module will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides common building blocks for such configurations - router instances, routes, routing tables, routing protocols and route filters. | ||||||||||||||||
| draft-ietf-netmod-smi-yang-05.txt | |||||||||||||||||
| Translation of SMIv2 MIB Modules to YANG Modules | |||||||||||||||||
|
YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the SNMP protocol. This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. | ||||||||||||||||
| draft-ietf-netmod-system-mgmt-00.txt | |||||||||||||||||
| YANG Data Model for System Management | |||||||||||||||||
|
This document defines a YANG data model for the configuration and identification of the management system of a device. | ||||||||||||||||
| draft-ietf-nfsv4-federated-fs-admin-10.txt | |||||||||||||||||
| Administration Protocol for Federated Filesystems | |||||||||||||||||
|
This document describes the administration protocol for a federated file system that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. | ||||||||||||||||
| draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13.txt | |||||||||||||||||
| Using DNS SRV to Specify a Global File Name Space with NFS version 4 | |||||||||||||||||
|
The NFS version 4 protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple way for an organization to publish the root of its filesystem name space, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization- wide file name spaces together to allow construction of a global, uniform NFS file name space. | ||||||||||||||||
| draft-ietf-nfsv4-federated-fs-protocol-12.txt | |||||||||||||||||
| NSDB Protocol for Federated Filesystems | |||||||||||||||||
|
This document describes a filesystem federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. | ||||||||||||||||
| draft-ietf-nfsv4-labreqs-03.txt | |||||||||||||||||
| Requirements for Labeled NFS | |||||||||||||||||
|
This Internet-Draft outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into NFSv4.2. It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. It also gives a brief explanation of what kinds of protections MAC systems offer. | ||||||||||||||||
| draft-ietf-nfsv4-migration-issues-00.txt | |||||||||||||||||
| NFSv4 migration: Implementation experience and spec issues to resolve | |||||||||||||||||
|
The migration feature of NFSv4 provides for moving responsibility for a single filesystem from one server to another, without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature. This document discusses the issues which have arisen and explores the options available for curing the issues via clarification and correction of the NFSv4.0 and NFSv4.1 specifications. | ||||||||||||||||
| draft-ietf-nfsv4-minorversion2-11.txt | |||||||||||||||||
| NFS Version 4 Minor Version 2 | |||||||||||||||||
|
This Internet-Draft describes NFS version 4 minor version two, focusing mainly on the protocol extensions made from NFS version 4 minor version 0 and NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor version two include: Server-side Copy, Application I/O Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. | ||||||||||||||||
| draft-ietf-nfsv4-minorversion2-dot-x-11.txt | |||||||||||||||||
| NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description | |||||||||||||||||
|
This Internet-Draft provides the XDR description for NFSv4 minor version two. | ||||||||||||||||
| draft-ietf-nfsv4-pnfs-block-disk-protection-02.txt | |||||||||||||||||
| pNFS block disk protection | |||||||||||||||||
|
Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to enable direct client access to file data on storage, bypassing the NFSv4 server. This can increase both performance and parallelism, but requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. | ||||||||||||||||
| draft-ietf-nfsv4-rfc3530bis-18.txt | |||||||||||||||||
| 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, replaces RFC 3530 as the definition of the NFS version 4 protocol. | ||||||||||||||||
| draft-ietf-nfsv4-rfc3530bis-dot-x-11.txt | |||||||||||||||||
| 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 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 RFC3530bis replaces RFC 3530 as the definition of the NFS version 4 protocol. | ||||||||||||||||
| draft-ietf-nfsv4-rfc5664bis-01.txt | |||||||||||||||||
| Object-Based Parallel NFS (pNFS) Operations | |||||||||||||||||
|
Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. | ||||||||||||||||
| draft-ietf-nfsv4-rpcsec-gssv3-02.txt | |||||||||||||||||
| Remote Procedure Call (RPC) Security Version 3 | |||||||||||||||||
|
This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides for: compound authentication of client hosts and users to server (constructed by generic composition), channel binding, security label assertions for multi-level and type enforcement, privilege assertions, and identity assertions. | ||||||||||||||||
| draft-ietf-oauth-assertions-03.txt | |||||||||||||||||
| OAuth 2.0 Assertion Profile | |||||||||||||||||
|
This specification provides a general framework for the use of assertions as client credentials and/or authorization grants with OAuth 2.0. It includes a generic mechanism for transporting assertions during interactions with a token endpoint, as wells as rules for the content and processing of those assertions. The intent is to provide an enhanced security profile by using derived values such as signatures or HMACs, as well as facilitate the use of OAuth 2.0 in client-server integration scenarios where the end-user may not be present. This specification only defines abstract message flow and assertion content. Actual use requires implementation of a companion protocol binding specification. Additional profile documents provide standard representations in formats such as SAML and JWT. | ||||||||||||||||
| draft-ietf-oauth-dyn-reg-00.txt | |||||||||||||||||
| OAuth Dynamic Client Registration Protocol | |||||||||||||||||
|
This specification proposes an OAuth Dynamic Client Registration protocol. | ||||||||||||||||
| draft-ietf-oauth-json-web-token-00.txt | |||||||||||||||||
| JSON Web Token (JWT) | |||||||||||||||||
|
JSON Web Token (JWT) is a means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed or MACed using JSON Web Signature (JWS) and/or encrypted using JSON Web Encryption (JWE). The suggested pronunciation of JWT is the same as the English word "jot". | ||||||||||||||||
| draft-ietf-oauth-jwt-bearer-00.txt | |||||||||||||||||
| JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 | |||||||||||||||||
|
This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. | ||||||||||||||||
| draft-ietf-oauth-saml2-bearer-12.txt | |||||||||||||||||
| SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 | |||||||||||||||||
|
This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. | ||||||||||||||||
| draft-ietf-oauth-urn-sub-ns-02.txt | |||||||||||||||||
| An IETF URN Sub-Namespace for OAuth | |||||||||||||||||
|
This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. | ||||||||||||||||
| draft-ietf-oauth-use-cases-00.txt | |||||||||||||||||
| OAuth Use Cases | |||||||||||||||||
|
This document lists the OAuth use cases. The provided list is based on the Internet-Drafts of the OAUTH working group and discussions on the group's mailing list. | ||||||||||||||||
| draft-ietf-oauth-v2-26.txt | |||||||||||||||||
| The OAuth 2.0 Authorization Framework | |||||||||||||||||
|
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. | ||||||||||||||||
| draft-ietf-oauth-v2-bearer-19.txt | |||||||||||||||||
| The OAuth 2.0 Authorization Protocol: Bearer Tokens | |||||||||||||||||
|
This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. | ||||||||||||||||
| draft-ietf-oauth-v2-http-mac-01.txt | |||||||||||||||||
| HTTP Authentication: MAC Access Authentication | |||||||||||||||||
|
This document specifies the HTTP MAC access authentication scheme, an HTTP authentication method using a message authentication code (MAC) algorithm to provide cryptographic verification of portions of HTTP requests. The document also defines an OAuth 2.0 binding for use as an access-token type. | ||||||||||||||||
| draft-ietf-oauth-v2-threatmodel-04.txt | |||||||||||||||||
| OAuth 2.0 Threat Model and Security Considerations | |||||||||||||||||
|
This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 Protocol. | ||||||||||||||||
| draft-ietf-opsawg-automated-network-configuration-03.txt | |||||||||||||||||
| Problem Statement for the Automated Configuration of Large IP Networks | |||||||||||||||||
|
This memo discusses the steps required to bring a large number of devices into service in IP networks in an automated fashion. The goal of this document is to list known solutions where they exist and to identify gaps that require further specifications. | ||||||||||||||||
| draft-ietf-opsawg-lsn-deployment-00.txt | |||||||||||||||||
| CGN Deployment with BGP/MPLS IP VPNs | |||||||||||||||||
|
This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). CGN is a concept also described in [I-D.ietf-behave-lsn-requirements] and describes the model as a dual layer translation model. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows CGN to be integrated into the network meeting the connectivity needs of the customer while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model includes the use of BGP/MPLS IP VPNs defined in [RFC4364] as a tool to achieve this goal. This document does not intend to defend the merits of CGN. | ||||||||||||||||
| draft-ietf-opsawg-management-stds-07.txt | |||||||||||||||||
| An Overview of the IETF Network Management Standards | |||||||||||||||||
|
This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover OAM technologies on the data-path, e.g. OAM of tunnels, MPLS-TP OAM, and Pseudowire as well as the corresponding management models. | ||||||||||||||||
| draft-ietf-opsawg-oam-overview-06.txt | |||||||||||||||||
| An Overview of Operations,Administration,and Maintenance (OAM) Mechanisms | |||||||||||||||||
|
Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. | ||||||||||||||||
| draft-ietf-opsec-efforts-18.txt | |||||||||||||||||
| Security Best Practices Efforts and Documents | |||||||||||||||||
|
This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). | ||||||||||||||||
| draft-ietf-opsec-icmp-filtering-03.txt | |||||||||||||||||
| Recommendations for filtering ICMP messages | |||||||||||||||||
|
This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. | ||||||||||||||||
| draft-ietf-ospf-hybrid-bcast-and-p2mp-02.txt | |||||||||||||||||
| OSPF Hybrid Broadcast and P2MP Interface Type | |||||||||||||||||
|
This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as LSA database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF. This document updates both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. | ||||||||||||||||
| draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.txt | |||||||||||||||||
| Routing for IPv4-embedded IPv6 Packets | |||||||||||||||||
|
This document describes routing packets destined to IPv4-embedded IPv6 addresses across IPv6 transit core using OSPFv3 with a separate routing table. | ||||||||||||||||
| draft-ietf-ospf-prefix-hiding-03.txt | |||||||||||||||||
| Hiding Transit-only Networks in OSPF | |||||||||||||||||
|
A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and minimize remote attack vulnerability. | ||||||||||||||||
| draft-ietf-ospf-security-extension-manual-keying-02.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-ospf-te-metric-extensions-01.txt | |||||||||||||||||
| 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 Express Path 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. | ||||||||||||||||
| draft-ietf-ospf-transport-instance-08.txt | |||||||||||||||||
| OSPF Transport Instance Extensions | |||||||||||||||||
|
OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. | ||||||||||||||||
| draft-ietf-p2psip-base-21.txt | |||||||||||||||||
| REsource LOcation And Discovery (RELOAD) Base Protocol | |||||||||||||||||
|
This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. | ||||||||||||||||
| draft-ietf-p2psip-diagnostics-08.txt | |||||||||||||||||
| P2PSIP Overlay Diagnostics | |||||||||||||||||
|
This document describes mechanisms for P2PSIP diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in a P2PSIP overlay networks. | ||||||||||||||||
| draft-ietf-p2psip-drr-01.txt | |||||||||||||||||
| An extension to RELOAD to support Direct Response Routing | |||||||||||||||||
|
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 intermediary peers and describes the potential cases where this extension can be used. | ||||||||||||||||
| draft-ietf-p2psip-rpr-01.txt | |||||||||||||||||
| An extension to RELOAD to support Relay Peer Routing | |||||||||||||||||
|
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 intermediary peers and describes the potential cases where this extension can be used. | ||||||||||||||||
| draft-ietf-p2psip-self-tuning-05.txt | |||||||||||||||||
| A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) | |||||||||||||||||
|
REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. | ||||||||||||||||
| draft-ietf-p2psip-service-discovery-05.txt | |||||||||||||||||
| Service Discovery Usage for REsource LOcation And Discovery (RELOAD) | |||||||||||||||||
|
REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism. | ||||||||||||||||
| draft-ietf-p2psip-sip-07.txt | |||||||||||||||||
| A SIP Usage for RELOAD | |||||||||||||||||
|
This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. | ||||||||||||||||
| draft-ietf-paws-problem-stmt-usecases-rqmts-04.txt | |||||||||||||||||
| Protocol to Access White Space database: PS,use cases and rqmts | |||||||||||||||||
|
Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. | ||||||||||||||||
| draft-ietf-payload-rtp-g718-02.txt | |||||||||||||||||
| RTP Payload Format for G.718 Speech/Audio | |||||||||||||||||
|
This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/ audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included. | ||||||||||||||||
| draft-ietf-payload-rtp-sbc-02.txt | |||||||||||||||||
| RTP Payload Format for Bluetooth's SBC Audio Codec | |||||||||||||||||
|
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. | ||||||||||||||||
| draft-ietf-payload-vp8-04.txt | |||||||||||||||||
| RTP Payload Format for VP8 Video | |||||||||||||||||
|
This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. | ||||||||||||||||
| draft-ietf-pce-enhanced-errors-00.txt | |||||||||||||||||
| Extension to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications | |||||||||||||||||
|
This document defines new error and notification TLVs for the PCE Communication Protocol (PCEP) [RFC5440]. It identifies the possible PCEP behaviors in case of error or notification. Thus, this draft extends error and notification types in order to associate predefined PCEP behaviors. | ||||||||||||||||
| draft-ietf-pce-gmpls-aps-req-05.txt | |||||||||||||||||
| Document: | |||||||||||||||||
|
The initial effort of PCE WG is specifically focused on MPLS (Multi- protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). | ||||||||||||||||
| draft-ietf-pce-gmpls-pcep-extensions-05.txt | |||||||||||||||||
| PCEP extensions for GMPLS | |||||||||||||||||
|
This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. | ||||||||||||||||
| draft-ietf-pce-hierarchy-fwk-02.txt | |||||||||||||||||
| The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS | |||||||||||||||||
|
Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture. Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply-connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward Recursive Path Computation Procedure (BRPC) can be used to derive an optimal path. This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. | ||||||||||||||||
| draft-ietf-pce-inter-area-as-applicability-02.txt | |||||||||||||||||
| Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering | |||||||||||||||||
|
The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks. | ||||||||||||||||
| draft-ietf-pce-inter-layer-ext-06.txt | |||||||||||||||||
| Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering | |||||||||||||||||
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. | ||||||||||||||||
| draft-ietf-pce-pcep-domain-sequence-00.txt | |||||||||||||||||
| Standard Representation Of Domain Sequence | |||||||||||||||||
|
The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement for P2P and P2MP scenarios. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a standard representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain. This document also defines new sub-objects to be used to encode domain identifiers. | ||||||||||||||||
| draft-ietf-pce-pcep-inter-domain-p2mp-procedures-02.txt | |||||||||||||||||
| 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 the procedures and extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of inter-domain paths for P2MP TE LSPs. | ||||||||||||||||
| draft-ietf-pce-stateful-pce-00.txt | |||||||||||||||||
| 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 this functionality, providing stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP. | ||||||||||||||||
| draft-ietf-pce-vendor-constraints-05.txt | |||||||||||||||||
| 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. The mechanisms defined for indicating objective functions include the capability to convey vendor-specific objective functions. This document defines a facility to carry vendor-specific constraints in PCEP. | ||||||||||||||||
| draft-ietf-pce-wson-routing-wavelength-07.txt | |||||||||||||||||
| PCEP Requirements for WSON Routing and Wavelength Assignment | |||||||||||||||||
|
This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for Optical impairments will be addressed in a separate document. | ||||||||||||||||
| draft-ietf-pcn-3-in-1-encoding-11.txt | |||||||||||||||||
| Encoding 3 PCN-States in the IP header using a single DSCP | |||||||||||||||||
|
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to decision points which then decide whether to admit or block new flow requests or to terminate some already-admitted flows during serious pre-congestion. This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational Appendix. The encoding for IP provides for up to three different PCN marking states using a single DSCP: Not-marked (NM), Threshold-marked (ThM) and Excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC5696. | ||||||||||||||||
| draft-ietf-pcn-3-state-encoding-02.txt | |||||||||||||||||
| A PCN encoding using 2 DSCPs to provide 3 or more states | |||||||||||||||||
|
Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows within a controlled domain. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This experimental encoding scheme specifies how three encoding states can be carried in the IP header using a combination of two DSCPs and the ECN bits. The Basic scheme only allows for three encoding states. The Full scheme provides 6 states, enough for limited end- to-end support for ECN as well. | ||||||||||||||||
| draft-ietf-pcn-cl-edge-behaviour-15.txt | |||||||||||||||||
| PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation | |||||||||||||||||
|
Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using three PCN marking states, not- marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN-boundary-node behaviour. | ||||||||||||||||
| draft-ietf-pcn-encoding-comparison-09.txt | |||||||||||||||||
| Overview of Pre-Congestion Notification Encoding | |||||||||||||||||
|
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre- congestion. The PCN Working Group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of all those approaches along with an explanation of the constraints that had to be met by any solution. | ||||||||||||||||
| draft-ietf-pcn-psdm-encoding-02.txt | |||||||||||||||||
| PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding) | |||||||||||||||||
|
Pre-congestion notification (PCN) is a link-specific and load- dependent packet re-marking mechanism and provides in Differentiated Services networks feedback to egress nodes about load conditions within the domain. It is used to support admission control and flow termination decision in a simple way. This document proposes how PCN marks can be encoded into the IP header for packet-specific dual marking (PSDM). PSDM encoding provides three different codepoints: not-ETM, not-ThM, and PM. Excess-traffic-marking may re-mark not- ETM-packets to PM and threshold-marking may re-mark not-ThM-packets to PM. | ||||||||||||||||
| draft-ietf-pcn-signaling-requirements-08.txt | |||||||||||||||||
| Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain | |||||||||||||||||
|
Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the decision point;(2) the decision point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors, "controlled load (CL)" and "single marking (SM)". | ||||||||||||||||
| draft-ietf-pcn-sm-edge-behaviour-12.txt | |||||||||||||||||
| PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation | |||||||||||||||||
|
Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using two PCN marking states, not- marked, and excess-traffic-marked. This behaviour is known informally as the Single Marking (SM) PCN-boundary-node behaviour. | ||||||||||||||||
| draft-ietf-pcp-base-25.txt | |||||||||||||||||
| Port Control Protocol (PCP) | |||||||||||||||||
|
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. | ||||||||||||||||
| draft-ietf-pcp-dhcp-03.txt | |||||||||||||||||
| DHCP Options for the Port Control Protocol (PCP) | |||||||||||||||||
|
This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server names. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenario. | ||||||||||||||||
| draft-ietf-pcp-proxy-00.txt | |||||||||||||||||
| Port Control Protocol (PCP) Proxy Function | |||||||||||||||||
|
This document specifies the behavior of a PCP Proxy element, for instance embedded in Customer Premise routers. | ||||||||||||||||
| draft-ietf-pcp-upnp-igd-interworking-01.txt | |||||||||||||||||
| 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. An UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP routers to allow for transparent NAT control in environments where UPnP is used in the LAN side and PCP in the external side of the CP router. | ||||||||||||||||
| draft-ietf-pim-drlb-01.txt | |||||||||||||||||
| Protocol Independent Multicast DR Load Balancing | |||||||||||||||||
|
On a multi-access network such as an Ethernet, one of the PIM routers is elected as a Designated Router (DR). The PIM DR has two roles in the PIM protocol. On the first hop network, the PIM DR is responsible for registering an active source to the RP if the group is operated in PIM SM. On the last hop network, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operated in PIM SM/SSM/DM. In this document, we propose a modification to the PIM protocol that allows more than one of these last hop routers to be selected so that the forwarding load can be distributed to and handled among these routers. A router responsible for forwarding for a particular group is called a Group Designated Router (GDR). | ||||||||||||||||
| draft-ietf-pim-ecmp-03.txt | |||||||||||||||||
| Protocol Independent Multicast ECMP Redirect | |||||||||||||||||
|
A Protocol Independent Multicast (PIM) [RFC4601] router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router to build forwarding state. When there are equal cost multiple paths (ECMP), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP path selection to be based on administratively selected metrics, such as data transmission delays, path preferences and routing metrics. | ||||||||||||||||
| draft-ietf-pim-explicit-tracking-01.txt | |||||||||||||||||
| IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers | |||||||||||||||||
|
This document describes the IGMP/MLD-based explicit membership tracking function for multicast routers. The explicit tracking function is useful for accounting and contributes to saving network resource and fast leaves (i.e. shortened leave latency). | ||||||||||||||||
| draft-ietf-pim-pop-count-06.txt | |||||||||||||||||
| Population Count Extensions to PIM | |||||||||||||||||
|
This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the PIM protocol allow a rough approximation of tree-based data in a scalable fashion. | ||||||||||||||||
| draft-ietf-pkix-caa-07.txt | |||||||||||||||||
| DNS Certification Authority Authorization (CAA) Resource Record | |||||||||||||||||
|
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis- issue. | ||||||||||||||||
| draft-ietf-pkix-cmc-serverkeygeneration-00.txt | |||||||||||||||||
| CMC Extensions: Server Key Generation | |||||||||||||||||
|
This document defines a set of extensions to the Certificate Management over CMS (CMC) protocol that addresses the desire to support server-side generation of keys. This service is provided by the definition of additional control statements within the CMC architecture. Additional CMC errors are also defined. | ||||||||||||||||
| draft-ietf-pkix-cmp-transport-protocols-19.txt | |||||||||||||||||
| Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP | |||||||||||||||||
|
This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced in RFC 4210 and therefore updates the reference given therein. | ||||||||||||||||
| draft-ietf-pkix-est-01.txt | |||||||||||||||||
| Enrollment over Secure Transport | |||||||||||||||||
|
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 simple Public Key Infrastructure clients that need to acquire client certificate(s) and associated Certification Authority (CA) certificate(s). | ||||||||||||||||
| draft-ietf-pkix-pubkey-caps-07.txt | |||||||||||||||||
| S/MIME Capabilities for Public Key Definitions | |||||||||||||||||
|
This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. An example of where this is used is is detailed in Online Certificate Status Protocol Algorithm Agility (RFC 6277). | ||||||||||||||||
| draft-ietf-pkix-rfc5280-clarifications-04.txt | |||||||||||||||||
| Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile | |||||||||||||||||
|
This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. | ||||||||||||||||
| draft-ietf-ppsp-peer-protocol-01.txt | |||||||||||||||||
| Peer-to-Peer Streaming Peer Protocol (PPSPP) | |||||||||||||||||
|
The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a peer-to-peer based transport protocol for content dissemination. It can be used for streaming on-demand and live video content, as well as conventional downloading. In PPSPP, the clients consuming the content participate in the dissemination by forwarding the content to other clients via a mesh-like structure. It is a generic protocol which can run directly on top of UDP, TCP, or as a RTP profile. Features of PPSPP are short time-till-playback and extensibility. Hence, it can use different mechanisms to prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). Depending on the underlying transport protocol, PPSPP can also use different congestion control algorithms, such as LEDBAT, and offer transparent NAT traversal. Finally, PPSPP maintains only a small amount of state per peer and detects malicious modification of content. This documents describes PPSPP and how it satisfies the requirements for the IETF Peer-to-Peer Streaming Protocol (PPSP) Working Group's peer protocol. | ||||||||||||||||
| draft-ietf-ppsp-problem-statement-08.txt | |||||||||||||||||
| 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 a Peer to Peer Streaming Protocol (PPSP) including tracker and peer signaling components, and discusses the scope, uses cases and requirements of PPSP. | ||||||||||||||||
| draft-ietf-precis-framework-03.txt | |||||||||||||||||
| PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols | |||||||||||||||||
|
Application protocols using Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to handle various classes of strings in a way that depends on the properties of Unicode code points and that 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 base string classes or subclass the base string classes as needed. This framework takes an approach similar to the revised internationalized domain names 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 RFC 4690, albeit for application technologies other than the Domain Name System (DNS). This document obsoletes RFC 3454. | ||||||||||||||||
| draft-ietf-precis-problem-statement-05.txt | |||||||||||||||||
| Stringprep Revision Problem Statement | |||||||||||||||||
|
Using Unicode codepoints in protocol strings that expect comparison with other strings requires preparation of the string that contains the Unicode codepoints. Internationalizing Domain Names in Applications (IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement. | ||||||||||||||||
| draft-ietf-pwe3-cbit-negotiation-03.txt | |||||||||||||||||
| Pseudowire Control Word Negotiation Mechanism Update | |||||||||||||||||
|
This document describes the problem of control word negotiation mechanism specified in [RFC4447]. Based on the problem analysis, a message exchanging mechanism is introduced to solve this control word negotiation issue. This document is to update [RFC4447] control word negotiation mechanism. | ||||||||||||||||
| draft-ietf-pwe3-iccp-07.txt | |||||||||||||||||
| Inter-Chassis Communication Protocol for L2VPN PE Redundancy | |||||||||||||||||
|
This document specifies an inter-chassis communication protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. | ||||||||||||||||
| draft-ietf-pwe3-mpls-eth-oam-iwk-05.txt | |||||||||||||||||
| MPLS and Ethernet OAM Interworking | |||||||||||||||||
|
This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects. | ||||||||||||||||
| draft-ietf-pwe3-mpls-tp-oam-config-00.txt | |||||||||||||||||
| Label Distribution Protocol Extensions for Proactive Operations,Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire | |||||||||||||||||
|
This document specifies extensions to the Label Distribution Protocol (LDP) to configure and control proactive Operations, Adminstration and Maintenance (OAM) functions, suitable for dynamic Single-Segment PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS-PW). | ||||||||||||||||
| draft-ietf-pwe3-p2mp-pw-04.txt | ||||||||||||||
| Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP | ||||||||||||||
|
This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. | |||||||||||||
| draft-ietf-pwe3-packet-pw-04.txt | |||||||||||||||||
| Packet Pseudowire Encapsulation over an MPLS PSN | |||||||||||||||||
|
This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. | ||||||||||||||||
| draft-ietf-pwe3-pw-typed-wc-fec-03.txt | |||||||||||||||||
| LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements | |||||||||||||||||
|
The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. | ||||||||||||||||
| draft-ietf-pwe3-redundancy-08.txt | |||||||||||||||||
| Pseudowire Redundancy | |||||||||||||||||
|
This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single -segment PW applications, or between terminating PE (T-PE) nodes in multi-segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. | ||||||||||||||||
| draft-ietf-pwe3-redundancy-bit-07.txt | |||||||||||||||||
| Pseudowire Preferential Forwarding Status Bit | |||||||||||||||||
|
This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. Finally, this document updates the PW operational status textual convention defined in RFC 5542 [9]. | ||||||||||||||||
| draft-ietf-pwe3-vccv-for-gal-01.txt | |||||||||||||||||
| A Unified Control Channel for Pseudowires | |||||||||||||||||
|
This document describes a unified mode of operation for Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW). VCCV applies to all supported access circuit and transport types currently defined for PWs, as well as those being transported by The MPLS Transport Profile. This new mode is intended to augment those described in RFC5085, but this document describes new rules requiring this mode to be used as the default/mandatory mode of operation for VCCV. The older types will remain optional. | ||||||||||||||||
| draft-ietf-pwe3-vccv-impl-survey-results-00.txt | |||||||||||||||||
| The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results | |||||||||||||||||
|
Most Pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) in order to better emulate the services for which the encapsulations have been defined. However, some encapulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. | ||||||||||||||||
| draft-ietf-radext-ieee802ext-01.txt | |||||||||||||||||
| 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 providing 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. | ||||||||||||||||
| draft-ietf-radext-ipv6-access-07.txt | |||||||||||||||||
| RADIUS attributes for IPv6 Access Networks | |||||||||||||||||
|
This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. | ||||||||||||||||
| draft-ietf-radext-radius-extensions-05.txt | |||||||||||||||||
| Remote Authentication Dial In User Service (RADIUS) Protocol Extensions | |||||||||||||||||
|
The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. | ||||||||||||||||
| draft-ietf-radext-radsec-12.txt | |||||||||||||||||
| Transport Layer Security (TLS) encryption for RADIUS | |||||||||||||||||
|
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. | ||||||||||||||||
| draft-ietf-radext-tcp-transport-09.txt | |||||||||||||||||
| RADIUS Over TCP | |||||||||||||||||
|
The Remote Authentication Dial In User Server (RADIUS) Protocol has until now required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentialy and security. | ||||||||||||||||
| draft-ietf-repute-email-identifiers-03.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-repute-media-type-02.txt | |||||||||||||||||
| A Media Type for Reputation Interchange | |||||||||||||||||
|
This document defines a media type for exchanging reputation information about an arbitrary class of object. | ||||||||||||||||
| draft-ietf-repute-model-01.txt | |||||||||||||||||
| A Model for Reputation Reporting | |||||||||||||||||
|
This document describes a general architecture for a reputation-based service and a model for the exchange of reputation information on the Internet. The document roughly follows the recommendations of RFC4101 for describing a protocol model. | ||||||||||||||||
| draft-ietf-repute-query-http-02.txt | |||||||||||||||||
| Reputation Data Interchange using HTTP and JSON | |||||||||||||||||
|
This document defines a mechanism to conduct queries for reputation information using the Hypertext Transfer Protocol. | ||||||||||||||||
| draft-ietf-rmt-fcast-05.txt | |||||||||||||||||
| FCAST: Scalable Object Delivery for the ALC and NORM Protocols | |||||||||||||||||
|
This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service. | ||||||||||||||||
| draft-ietf-rmt-flute-revised-14.txt | |||||||||||||||||
| FLUTE - File Delivery over Unidirectional Transport | |||||||||||||||||
|
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC3926. | ||||||||||||||||
| draft-ietf-rmt-flute-sdp-02.txt | |||||||||||||||||
| SDP Descriptors for FLUTE | |||||||||||||||||
|
This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions. It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions. | ||||||||||||||||
| draft-ietf-roll-applicability-ami-06.txt | |||||||||||||||||
| Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks | |||||||||||||||||
|
This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. | ||||||||||||||||
| draft-ietf-roll-minrank-hysteresis-of-10.txt | |||||||||||||||||
| The Minimum Rank with Hysteresis Objective Function | |||||||||||||||||
|
The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. | ||||||||||||||||
| draft-ietf-roll-p2p-measurement-05.txt | |||||||||||||||||
| A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network | |||||||||||||||||
|
This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. | ||||||||||||||||
| draft-ietf-roll-p2p-rpl-12.txt | |||||||||||||||||
| Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks | |||||||||||||||||
|
This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. | ||||||||||||||||
| draft-ietf-roll-security-framework-07.txt | |||||||||||||||||
| A Security Framework for Routing over Low Power and Lossy Networks | |||||||||||||||||
|
This document presents a security framework 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 and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). | ||||||||||||||||
| draft-ietf-rtcweb-data-channel-00.txt | |||||||||||||||||
| RTCWeb Datagram Connection | |||||||||||||||||
|
The Web Real-Time Communication (WebRTC) working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document describes the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing Web Browser to exchange generic data from peer to peer. | ||||||||||||||||
| draft-ietf-rtcweb-jsep-00.txt | |||||||||||||||||
| Javascript Session Establishment Protocol | |||||||||||||||||
|
This document proposes a mechanism for allowing a Javascript application to fully control the signaling plane of a multimedia session, and discusses how this would work with existing signaling protocols. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. | ||||||||||||||||
| draft-ietf-rtcweb-overview-03.txt | |||||||||||||||||
| Overview: Real Time Protocols for Brower-based Applications | |||||||||||||||||
|
This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion, unless the RTCWEB chairs have declared consensus on an item. This document is a work item of the RTCWEB working group. | ||||||||||||||||
| draft-ietf-rtcweb-rtp-usage-02.txt | |||||||||||||||||
| Web Real-Time Communication (WebRTC): Media Transport and Use of RTP | |||||||||||||||||
|
The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. | ||||||||||||||||
| draft-ietf-rtcweb-security-02.txt | |||||||||||||||||
| Security Considerations for RTC-Web | |||||||||||||||||
|
The Real-Time Communications on the Web (RTC-Web) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTC-Web technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTC-Web communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the RTC-Web threat model and defines an architecture which provides security within that threat model. | ||||||||||||||||
| draft-ietf-rtcweb-security-arch-01.txt | |||||||||||||||||
| RTCWEB Security Architecture | |||||||||||||||||
|
The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTCWEB technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTCWEB communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. [I-D.ietf- rtcweb-security] defines the RTCWEB threat model. This document defines an architecture which provides security within that threat model. | ||||||||||||||||
| draft-ietf-rtcweb-use-cases-and-requirements-07.txt | |||||||||||||||||
| Web Real-Time Communication Use-cases and Requirements | |||||||||||||||||
|
This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream services provided by the browser. | ||||||||||||||||
| draft-ietf-rtgwg-cl-requirement-05.txt | |||||||||||||||||
| Requirements for MPLS Over a Composite Link | |||||||||||||||||
|
There is often a need to provide large aggregates of bandwidth that are best provided using parallel links between routers or MPLS LSR. In core networks there is often no alternative since the aggregate capacities of core networks today far exceed the capacity of a single physical link or single packet processing element. The presence of parallel links, with each link potentially comprised of multiple layers has resulted in additional requirements. Certain services may benefit from being restricted to a subset of the component links or a specific component link, where component link characteristics, such as latency, differ. Certain services require that an LSP be treated as atomic and avoid reordering. Other services will continue to require only that reordering not occur within a microflow as is current practice. Current practice related to multipath is described briefly in an appendix. | ||||||||||||||||
| draft-ietf-rtgwg-ipfrr-ip-mib-02.txt | |||||||||||||||||
| IP MIB for IP Fast-Reroute | |||||||||||||||||
|
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 relevant for IP routes using IP Fast-Reroute [RFC5714]. | ||||||||||||||||
| draft-ietf-rtgwg-ipfrr-notvia-addresses-08.txt | |||||||||||||||||
| IP Fast Reroute Using Not-via Addresses | |||||||||||||||||
|
This draft describes a mechanism that provides fast reroute in an IP network through encapsulation to "not-via" addresses. A single level of encapsulation is used. The mechanism protects unicast, multicast and LDP traffic against link, router and shared risk group failure, regardless of network topology and metrics. | ||||||||||||||||
| draft-ietf-rtgwg-lfa-applicability-06.txt | |||||||||||||||||
| LFA applicability in SP networks | |||||||||||||||||
|
In this document, we analyze the applicability of the Loop-Free Alternates method of providing IP fast re-route in both the core and the access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFA to different network topologies, with special emphasis on the access parts of the network. | ||||||||||||||||
| draft-ietf-rtgwg-mrt-frr-architecture-01.txt | |||||||||||||||||
| An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees | |||||||||||||||||
|
As IP and LDP Fast-Reroute are increasingly deployed, the coverage limitations of Loop-Free Alternates are seen as a problem that requires a straightforward and consistent solution for IP and LDP, for unicast and multicast. This draft describes an architecture based on redundant backup trees where a single failure can cut a point-of-local-repair from the destination only on one of the pair of redundant trees. One innovative algorithm to compute such topologies is maximally disjoint backup trees. Each router can compute its next-hops for each pair of maximally disjoint trees rooted at each node in the IGP area with computational complexity similar to that required by Dijkstra. The additional state, address and computation requirements are believed to be significantly less than the Not-Via architecture requires. | ||||||||||||||||
| draft-ietf-salud-alert-info-urns-06.txt | |||||||||||||||||
| Alert-Info URNs for the Session Initiation Protocol (SIP) | |||||||||||||||||
|
The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted. This is done using the Alert-Info header field. However, the reference addresses only network resources with specific rendering properties. There is currently no support for predefined standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome this limitation and support new applications, a new family of URNs for use in SIP Alert-Info header fields is defined in this specification. This document normatively updates [RFC3261], the Session Initiation Protocol (SIP). It changes the usage of the SIP Alert-Info header field defined in the [RFC3261] by additionally allowing its use in all provisional responses to INVITE (except the 100 response). | ||||||||||||||||
| draft-ietf-savi-dhcp-12.txt | |||||||||||||||||
| SAVI Solution for DHCP | |||||||||||||||||
|
This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets generated on the local link with forged source IP address. | ||||||||||||||||
| draft-ietf-savi-framework-06.txt | |||||||||||||||||
| Source Address Validation Improvement Framework | |||||||||||||||||
|
Source Address Validation Improvement methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer- grained, standardized IP source address validation. This document is a framework document, which describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents. | ||||||||||||||||
| draft-ietf-savi-mix-02.txt | |||||||||||||||||
| SAVI for Mixed Address Assignment Methods Scenario | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ietf-savi-send-07.txt | |||||||||||||||||
| SEND-based Source-Address Validation Implementation | |||||||||||||||||
|
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. | ||||||||||||||||
| draft-ietf-savi-threat-scope-05.txt | |||||||||||||||||
| SAVI Threat Scope | |||||||||||||||||
|
Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work. | ||||||||||||||||
| draft-ietf-sidr-algorithm-agility-05.txt | |||||||||||||||||
| Algorithm Agility Procedure for RPKI. | |||||||||||||||||
|
This document specifies the process that Certification Authorities (CAs) and Relying Parties (RP) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of months or years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). | ||||||||||||||||
| draft-ietf-sidr-bgpsec-algs-02.txt | |||||||||||||||||
| BGP Algorithms,Key Formats,& Signature Formats | |||||||||||||||||
|
This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPSEC (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (RFC 6485). | ||||||||||||||||
| draft-ietf-sidr-bgpsec-ops-05.txt | |||||||||||||||||
| BGPsec Operational Considerations | |||||||||||||||||
|
Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present them. It is expected to evolve as BGPsec is formalized and initially deployed. | ||||||||||||||||
| draft-ietf-sidr-bgpsec-overview-02.txt | |||||||||||||||||
| An Overview of BGPSEC | |||||||||||||||||
|
This document provides an overview of a security extension to the Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves security for BGP routing. | ||||||||||||||||
| draft-ietf-sidr-bgpsec-pki-profiles-03.txt | |||||||||||||||||
| A Profile for BGPSEC Router Certificates,Certificate Revocation Lists,and Certification Requests | |||||||||||||||||
|
This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS). The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS. This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). | ||||||||||||||||
| draft-ietf-sidr-bgpsec-protocol-03.txt | |||||||||||||||||
| BGPSEC Protocol Specification | |||||||||||||||||
|
This document describes BGPSEC, an extension to the Border Gateway Protocol (BGP) that provides security for the AS-PATH attribute in BGP update messages. BGPSEC is implemented via a new optional non- transitive BGP path attribute that carries a digital signature produced by each autonomous system on the AS-PATH. | ||||||||||||||||
| draft-ietf-sidr-bgpsec-reqs-03.txt | |||||||||||||||||
| Security Requirements for BGP Path Validation | |||||||||||||||||
|
This document describes requirements for a future BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. | ||||||||||||||||
| draft-ietf-sidr-bgpsec-threats-02.txt | |||||||||||||||||
| Threat Model for BGP Path Security | |||||||||||||||||
|
This document describes a threat model for BGP path security (BGPSEC). It assumes the context established by the SIDR WG charter, as of April 19, 2011. The charter established two goals for the SIDR work: o Enabling an AS to verify the authorization of an origin AS to originate a specified set of prefixes o Enabling an AS to verify that the AS-PATH represented in a route matches the path travelled by the NLRI for the route The charter further mandates that SIDR build upon the Resource Public Key Infrastructure (RPKI), the first product of the WG. Consistent with the charter, this threat model includes an analysis of the RPKI, and focuses on the ability of an AS to verify the authenticity of the AS path info received in a BGP update. The model assumes that BGP path security is achieved through the application of digital signatures to AS_Path Info. The document characterizes classes of potential adversaries that are considered to be threats, and examines classes of attacks that might be launched against BGPSEC. It concludes with brief discussion of residual vulnerabilities. | ||||||||||||||||
| draft-ietf-sidr-ltamgmt-04.txt | |||||||||||||||||
| Local Trust Anchor Management for the Resource Public Key Infrastructure | |||||||||||||||||
|
This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common to allow an RP to import TA material in the form of self-signed certificates. The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the relevant constraints are the RFC 3779 extensions that bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for this facility is to enable an RP to ensure that resource allocation information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of bindings between public key identifiers and RFC 3779 extension data and will override any conflicting bindings expressed via the putative TAs and the certificates downloaded from the RPKI repository system. Although this mechanism is designed for local use by an RP, an entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to a set of RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document. | ||||||||||||||||
| draft-ietf-sidr-origin-ops-16.txt | |||||||||||||||||
| RPKI-Based Origin Validation Operation | |||||||||||||||||
|
Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. | ||||||||||||||||
| draft-ietf-sidr-pfx-validate-06.txt | |||||||||||||||||
| BGP Prefix Origin Validation | |||||||||||||||||
|
To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. | ||||||||||||||||
| draft-ietf-sidr-publication-02.txt | |||||||||||||||||
| A Publication Protocol for the Resource Public Key Infrastructure (RPKI) | |||||||||||||||||
|
This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. This document provides the protocol for doing so. | ||||||||||||||||
| draft-ietf-sidr-rpki-rtr-26.txt | |||||||||||||||||
| The RPKI/Router Protocol | |||||||||||||||||
|
In order to verifiably validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. | ||||||||||||||||
| draft-ietf-sidr-rpki-rtr-impl-00.txt | |||||||||||||||||
| RPKI Router Implementation Report | |||||||||||||||||
|
This document provides an implementation report for RPKI Router protocol as defined in [I-D.ietf-sidr-rpki-rtr]. 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. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. | ||||||||||||||||
| draft-ietf-sidr-rpki-rtr-protocol-mib-00.txt | |||||||||||||||||
| Definitions of Managed Objects for the RPKI-Router Protocol | |||||||||||||||||
|
This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the RPKI Router protocol. | ||||||||||||||||
| draft-ietf-sidr-rpsl-sig-05.txt | |||||||||||||||||
| Securing RPSL Objects with RPKI Signatures | |||||||||||||||||
|
This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. | ||||||||||||||||
| draft-ietf-sidr-rtr-keying-00.txt | |||||||||||||||||
| Router Keying for BGPsec | |||||||||||||||||
|
BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global Resource PKI. This document describes two ways of doing so, router-driven and operator-driven. | ||||||||||||||||
| draft-ietf-sidr-usecases-04.txt | |||||||||||||||||
| Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties | |||||||||||||||||
|
This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. | ||||||||||||||||
| draft-ietf-sieve-imap-sieve-03.txt | |||||||||||||||||
| Support for Internet Message Access Protocol (IMAP) Events in Sieve | |||||||||||||||||
|
Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). | ||||||||||||||||
| draft-ietf-simple-chat-14.txt | |||||||||||||||||
| Multi-party Chat Using the Message Session Relay Protocol (MSRP) | |||||||||||||||||
|
The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. | ||||||||||||||||
| draft-ietf-simple-msrp-cema-05.txt | |||||||||||||||||
| Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) | |||||||||||||||||
|
This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of the extension is optional. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages, and thus also enables a secure end-to-end MSRP communication in networks where such middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. | ||||||||||||||||
| draft-ietf-simple-simple-07.txt | |||||||||||||||||
| SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP) | |||||||||||||||||
|
The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions. This document serves as a guide to the SIMPLE suite of specifications. It breaks them up into categories and explains what each is for and how they relate to each other. | ||||||||||||||||
| draft-ietf-sip-session-policy-framework-10.txt | |||||||||||||||||
| A Framework for Session Initiation Protocol (SIP) Session Policies | |||||||||||||||||
|
Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. | ||||||||||||||||
| draft-ietf-sipclf-format-06.txt | |||||||||||||||||
| Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) | |||||||||||||||||
|
The SIPCLF Workgroup has defined a common log format framework for Session Initiation Protocol (SIP) servers. This common log format mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP Common Log Format (CLF) that retains the key advantages of a text-based format, while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF data model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record. | ||||||||||||||||
| draft-ietf-sipclf-problem-statement-11.txt | |||||||||||||||||
| The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Data Model | |||||||||||||||||
|
Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. We propose a common log file format for SIP servers that can be used uniformly by user agents, proxies, registrars, redirect servers as well as back-to-back user agents. | ||||||||||||||||
| draft-ietf-sipcore-proxy-feature-02.txt | |||||||||||||||||
| Indication of features supported by proxy | |||||||||||||||||
|
This specification creates a new IANA registry, "SIP Feature Cap Registry", which is used to register indicators, "SIP feature caps", used by SIP entities to indicate support of features and capabilities, in cases where the Contact header field contains a URI that does not represent the SIP entity that wants to indicate support of its features and capabilities. This specification also defines a new SIP header field, Feature-Caps, that can be used by SIP entities to convey information about supported features and capabilities, using SIP feature caps. | ||||||||||||||||
| draft-ietf-sipcore-proxy-feature-reqs-03.txt | |||||||||||||||||
| Requirements for indication of features supported by a SIP proxy | |||||||||||||||||
|
The Session Initiation Protocol (SIP) "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/ capabilities. This document defines requirements for a mechanism that would allow SIP proxies to convey information relating to the proxy's supported features/capabilities. | ||||||||||||||||
| draft-ietf-sipcore-rfc3265bis-09.txt | |||||||||||||||||
| SIP-Specific Event Notification | |||||||||||||||||
|
This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. | ||||||||||||||||
| draft-ietf-sipcore-rfc4244bis-08.txt | |||||||||||||||||
| An Extension to the Session Initiation Protocol (SIP) for Request History Information | |||||||||||||||||
|
This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field This document obsoletes RFC 4244. | ||||||||||||||||
| draft-ietf-sipcore-sip-websocket-00.txt | |||||||||||||||||
| The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) | |||||||||||||||||
|
The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities and enables usage of the SIP protocol in new scenarios. | ||||||||||||||||
| draft-ietf-sipping-policy-package-08.txt | |||||||||||||||||
| A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies. | |||||||||||||||||
|
This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents to subscribe to session policies for a SIP session and to receive notifications if these policies change. | ||||||||||||||||
| draft-ietf-siprec-architecture-04.txt | |||||||||||||||||
| 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). | ||||||||||||||||
| draft-ietf-siprec-metadata-06.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-siprec-protocol-04.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-soc-load-control-event-package-03.txt | |||||||||||||||||
| A Session Initiation Protocol (SIP) Load Control Event Package | |||||||||||||||||
|
We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute load filters to other SIP servers in the network. The load filters contain rules to throttle calls based on their source or destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. | ||||||||||||||||
| draft-ietf-soc-overload-control-08.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ietf-soc-overload-rate-control-01.txt | |||||||||||||||||
| Session Initiation Protocol (SIP) Rate Control | |||||||||||||||||
|
The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already [draft-ietf-soc-overload-control-07] proposes a loss-based solution to remedy known vulnerabilities of the [RFC3261] SIP 503 (service unavailable) overload control mechanism. This document proposes a rate-based control solution to complement the loss-based control defined in [draft-ietf-soc-overload-control-07]. | ||||||||||||||||
| draft-ietf-softwire-4rd-00.txt | |||||||||||||||||
| IPv4 Residual Deployment via IPv6 - a unified Stateless Solution (4rd) | |||||||||||||||||
|
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, customers can be assigned IPv4 addresses with restricted port sets. In some scenarios, 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of [RFC6145]). | ||||||||||||||||
| draft-ietf-softwire-6rd-radius-attrib-05.txt | |||||||||||||||||
| RADIUS Attribute for 6rd | |||||||||||||||||
|
IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd 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 DHC protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. | ||||||||||||||||
| draft-ietf-softwire-dslite-deployment-03.txt | |||||||||||||||||
| Deployment Considerations for Dual-Stack Lite | |||||||||||||||||
|
This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. This document describes the various deployment considerations and applicability of the Dual-Stack Lite architecture. | ||||||||||||||||
| draft-ietf-softwire-dslite-multicast-02.txt | |||||||||||||||||
| Multicast Extensions to DS-Lite Technique in Broadband Deployments | |||||||||||||||||
|
This document specifies a solution for the delivery of multicast service offerings to DS-Lite serviced customers. The proposed solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic over an IPv6 multicast-enabled network. | ||||||||||||||||
| draft-ietf-softwire-gateway-init-ds-lite-08.txt | |||||||||||||||||
| Gateway Initiated Dual-Stack Lite Deployment | |||||||||||||||||
|
Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual- Stack lite (DS-lite) applicable to certain tunnel-based access architectures. GI-DS-lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded context identifier that uniquely identifies the end-system the tunneled packets belong to. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. | ||||||||||||||||
| draft-ietf-softwire-mesh-multicast-02.txt | |||||||||||||||||
| Softwire Mesh Multicast | |||||||||||||||||
|
The Internet needs to support IPv4 and IPv6 packets. Both address families and their attendant protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwires Mesh is a solution to E-IP unicast and multicast support across an I-IP backbone. This document describes the mechanisms for supporting Internet-style multicast across a set of E-IP and I-IP networks supporting softwires mesh. | ||||||||||||||||
| draft-ietf-softwire-multicast-prefix-option-00.txt | |||||||||||||||||
| DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes | |||||||||||||||||
|
This document defines Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast transition solutions, aiming to convey the IPv6 prefixes to be used to build unicast and multicast IPv4- embedded IPv6 addresses. | ||||||||||||||||
| draft-ietf-softwire-public-4over6-01.txt | |||||||||||||||||
| Public IPv4 over IPv6 Access Network | |||||||||||||||||
|
When the service provider networks are upgraded to IPv6, IPv4 connectivity will still be demanded by network users, at least in the recent future. This draft proposes a mechanism for end hosts or networks in IPv6 access networks to build bidirectional IPv4 communication with the IPv4 Internet. The mechanism follows the softwire hub and spoke model, and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network. The bi-directionality of end-to-end communication is achieved by allocating public IPv4 addresses to end hosts/networks. This mechanism is an IPv4 access method for network users in IPv6. | ||||||||||||||||
| draft-ietf-softwire-stateless-4v6-motivation-01.txt | |||||||||||||||||
| Motivations for Stateless IPv4 over IPv6 Migration Solutions | |||||||||||||||||
|
IPv4 service continuity is one of the most pressing problems that must be resolved by Service Providers during the IPv6 transition period - especially after the exhaustion of the public IPv4 address space. Current standardization effort that addresses IPv4 service continuity focuses on stateful mechanisms. This document elaborates on the motivations for the need to undertake a companion effort to specify stateless IPv4 over IPv6 approaches. | ||||||||||||||||
| draft-ietf-speechsc-mrcpv2-27.txt | |||||||||||||||||
| Media Resource Control Protocol Version 2 (MRCPv2) | |||||||||||||||||
|
The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. | ||||||||||||||||
| draft-ietf-spfbis-experiment-09.txt | |||||||||||||||||
| Resolution of The SPF and Sender ID Experiments | |||||||||||||||||
|
In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols. Both of these protocols enable one to publish via the Domain Name System a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents (RFC4405, RFC4406, RFC4407, and RFC4408) with Experimental status, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. | ||||||||||||||||
| draft-ietf-storm-iscsi-cons-05.txt | |||||||||||||||||
| iSCSI Protocol (Consolidated) | |||||||||||||||||
|
This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721 and RFC 3723. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. | ||||||||||||||||
| draft-ietf-storm-iscsi-sam-05.txt | |||||||||||||||||
| Internet Small Computer Systems Interface (iSCSI) SCSI Features Update | |||||||||||||||||
|
Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in [draft-ietf-storm- iscsi-cons-xx] (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a companion document to [draft-ietf-storm- iscsi-cons-xx]. -------------------------------------------------------- RFC EDITORS NOTE: The above references to [draft-ietf-storm- iscsi-cons-xx] should reference the RFC number assigned to that document, and this note should be removed. -------------------------------------------------------- | ||||||||||||||||
| draft-ietf-storm-iscsimib-01.txt | |||||||||||||||||
| Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) | |||||||||||||||||
|
This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). This document obsoletes RFC4544. | ||||||||||||||||
| draft-ietf-storm-iser-11.txt | |||||||||||||||||
| iSCSI Extensions for RDMA Specification | |||||||||||||||||
|
iSCSI Extensions for 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. | ||||||||||||||||
| draft-ietf-storm-rdmap-ext-02.txt | |||||||||||||||||
| RDMA Protocol Extensions | |||||||||||||||||
|
This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP [RFC5040]). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data. | ||||||||||||||||
| draft-ietf-tcpm-1323bis-02.txt | |||||||||||||||||
| TCP Extensions for High Performance | |||||||||||||||||
|
This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC 1323. | ||||||||||||||||
| draft-ietf-tcpm-3517bis-02.txt | |||||||||||||||||
| A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP | |||||||||||||||||
|
This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. | ||||||||||||||||
| draft-ietf-tcpm-experimental-options-00.txt | |||||||||||||||||
| Shared Use of Experimental TCP Options | |||||||||||||||||
|
This document describes how TCP option codepoints can support concurrent experiments. The suggested mechanism avoids the need for a coordinated registry, and is backward-compatible with currently known uses. | ||||||||||||||||
| draft-ietf-tcpm-fastopen-00.txt | |||||||||||||||||
| TCP Fast Open | |||||||||||||||||
|
TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus providing a saving of up to one full round trip time (RTT) compared to standard TCP requiring a three-way handshake (3WHS) to complete before data can be exchanged. Terminology | ||||||||||||||||
| draft-ietf-tcpm-initcwnd-03.txt | |||||||||||||||||
| Increasing TCP's Initial Window | |||||||||||||||||
|
This document proposes an increase in the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without risking congestion collapse. The document closes with a discussion of usage and deployment recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. Terminology | ||||||||||||||||
| draft-ietf-tcpm-proportional-rate-reduction-01.txt | |||||||||||||||||
| Proportional Rate Reduction for TCP | |||||||||||||||||
|
This document describes an experimental algorithm, Proportional Rate Reduction (PPR) to improve the accuracy of the amount of data sent by TCP during loss recovery. Standard Congestion Control requires that TCP and other protocols reduce their congestion window in response to losses. This window reduction naturally occurs in the same round trip as the data retransmissions to repair the losses, and is implemented by choosing not to transmit any data in response to some ACKs arriving from the receiver. Two widely deployed algorithms are used to implement this window reduction: Fast Recovery and Rate Halving. Both algorithms are needlessly fragile under a number of conditions, particularly when there is a burst of losses that such that the number of ACKs returning to the sender is small. Proportional Rate Reduction minimizes these excess window reductions such that at the end of recovery the actual window size will be as close as possible to ssthresh, the window size determined by the congestion control algorithm. It is patterned after Rate Halving, but using the fraction that is appropriate for target window chosen by the congestion control algorithm. | ||||||||||||||||
| draft-ietf-tcpm-tcp-security-03.txt | |||||||||||||||||
| Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations | |||||||||||||||||
|
This document surveys methods to harden Transmission Control Protocol (TCP) implementations. It provides an overview of known attacks and refers to the corresponding solutions in the TCP standards. | ||||||||||||||||
| draft-ietf-tcpm-tcpmss-04.txt | |||||||||||||||||
| TCP Options and MSS | |||||||||||||||||
|
This memo discusses what value to use with the TCP MSS option, and updates RFC 879 and RFC 2385. | ||||||||||||||||
| draft-ietf-tictoc-ptp-mib-01.txt | |||||||||||||||||
| Precision Time Protocol Version 2 (PTPv2) Management Information Base | |||||||||||||||||
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Precision Time Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. | ||||||||||||||||
| draft-ietf-tictoc-security-requirements-01.txt | |||||||||||||||||
| TICTOC Security Requirements | |||||||||||||||||
|
As time synchronization protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of requirements for security solutions for time synchronization protocols, focusing on the IEEE 1588 and NTP. This document also discusses the security impacts of time synchronization protocol practices, the time synchronization performance implications of external security practices, the dependencies between other security services and time synchronization. | ||||||||||||||||
| draft-ietf-tls-cached-info-11.txt | |||||||||||||||||
| Transport Layer Security (TLS) Cached Information Extension | |||||||||||||||||
|
Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted Certification Authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate path (including all intermediary certificates up to the trust anchor public key). This document defines an extension that omits the exchange of already available information. The TLS client informs a server of cached information, for example from a previous TLS handshake, allowing the server to omit the already available information. | ||||||||||||||||
| draft-ietf-tls-multiple-cert-status-extension-00.txt | |||||||||||||||||
| The TLS Multiple Certificate Status Request Extension | |||||||||||||||||
|
This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. | ||||||||||||||||
| draft-ietf-tls-oob-pubkey-03.txt | |||||||||||||||||
| TLS Out-of-Band Public Key Validation | |||||||||||||||||
|
This document specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation. Currently, TLS authentication can only occur via X.509-based Public Key Infrastructure (PKI) or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative public key validation methods. One such alternative public key valiation method is offered by the DNS-Based Authentication of Named Entities (DANE) together with DNS Security. Another alternative is to utilize pre-configured keys, as is the case with sensors and other embedded devices. The usage of raw public keys, instead of X.509-based certificates, leads to a smaller code footprint. The support for raw public keys is introduced into TLS via a new non- PKIX certificate type. | ||||||||||||||||
| draft-ietf-trill-clear-correct-03.txt | |||||||||||||||||
| TRILL: Clarifications,Corrections,and Updates | |||||||||||||||||
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Since the TRILL base protocol was approved in March 2010, active development of TRILL has revealed a few errata in the original RFC 6325 and some cases that could use clarifications or updates. RFC 6327 and RFC 6439 provide clarifications and updates with respect to Adjacency and Appointed Forwarders. This document provide other known clarifications, corrections, and updates to RFC 6325, RFC 6327, and RFC 6439. | ||||||||||||||||
| draft-ietf-trill-cmt-00.txt | |||||||||||||||||
| Coordinated Multicast Trees (CMT)for TRILL | |||||||||||||||||
|
TRILL facilitates loop free connectivity to non TRILL legacy networks via choice of an Appointed Forwarder for set of VLANs. Appointed Forwarder provides VLAN level load sharing with active- standby model. Mission critical operations such as High Performance Data Centers require active-active load sharing model. Active-Active load sharing model can be accomplished by representing any given non TRILL legacy network with a single virtual RBridge. Virtual representation of the non-TRILL legacy network with a single RBridge poses serious challenges in multi-destination RPF calculations. This document presents the required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues. CMT provides flexibility to RBridges to select desired path of association to a given distribution tree. | ||||||||||||||||
| draft-ietf-trill-fine-labeling-00.txt | |||||||||||||||||
| TRILL: Fine-Grained Labeling | |||||||||||||||||
|
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 encapsulation with a hop count. The TRILL base protocol standard supports labeling of TRILL data with up to 4K IDs. However, there are applications that require more fine- grained labeling of data. This document updates RFC 6325 by specifying extensions to the TRILL base protocol to accomplish this. | ||||||||||||||||
| draft-ietf-trill-rbridge-bfd-05.txt | |||||||||||||||||
| TRILL: Bidirectional Forwarding Detection (BFD) Support | |||||||||||||||||
|
This document specifies use of the BFD (Bidirectional Forwarding Detection) protocol in RBridge campuses based on the Rbridge Channel extension to the the TRILL (TRansparent Interconnection of Lots of Links) protocol. BFD is a widely deployed OAM (Operations, Administration, and Maintenance) mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively. This document specifies the BFD encapsulation over TRILL. | ||||||||||||||||
| draft-ietf-trill-rbridge-channel-06.txt | |||||||||||||||||
| TRILL: RBridge Channel Support | |||||||||||||||||
|
This document specifies a general channel mechanism for sending messages, such as BFD (Bidirectional Forwarding Detection) messages, between RBridges (Routing Bridges) and between RBridges and end stations in an RBridge campus through extensions to the TRILL (TRansparent Interconnection of Lots of Links) protocol. | ||||||||||||||||
| draft-ietf-trill-rbridge-extension-04.txt | |||||||||||||||||
| TRILL: Header Extension | |||||||||||||||||
|
The IETF TRILL (Transparent Interconnection of Lots of Links) base protocol specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies two of those bits. | ||||||||||||||||
| draft-ietf-trill-rbridge-mib-07.txt | |||||||||||||||||
| Definitions of Managed Objects for RBridges (Routing Bridges) | |||||||||||||||||
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing an RBridge (Routing Bridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. | ||||||||||||||||
| draft-ietf-trill-rbridge-oam-02.txt | |||||||||||||||||
| Routing Bridges (RBridges): Operations,Administration,and Maintenance (OAM) Support | |||||||||||||||||
|
Routing Bridges (RBridges) implement the TRansparent Interconnection of Lots of Links (TRILL) protocol which provide a transparent least- cost frame routing in multi-hop networks with arbitrary topologies, while also inherently providing loop mitigation. As RBridges are deployed in real-world situations, operators will need tools for debugging problems that arise. This document specifies a set of RBridge features for operations, administration, and maintenance (OAM) purposes in RBridge campuses. The features specified in this document include tools for traceroute, ping, and error reporting. | ||||||||||||||||
| draft-ietf-trill-rbridge-options-06.txt | |||||||||||||||||
| RBridges: Further TRILL Header Extensions | |||||||||||||||||
|
The TRILL base protocol standard specifies minimal hooks to safely support TRILL Header extensions. Initial extensions have been specified in RFC [ExtendHeader]. This document specifies the format for further such extensions and specifies some further specific extensions. | ||||||||||||||||
| draft-ietf-trill-rbridge-vlan-mapping-07.txt | |||||||||||||||||
| RBridges: Campus VLAN and Priority Regions | |||||||||||||||||
|
Within an RBridge campus, the VLAN and priority of TRILL encapsulated frames is preserved. However, in some cases it may be desired that data VLAN and/or priority be mapped at the boundary between regions of such a campus. This document describes an optional RBridge feature to provide this function. | ||||||||||||||||
| draft-ietf-tsvwg-byte-pkt-congest-07.txt | |||||||||||||||||
| Byte and Packet Congestion Notification | |||||||||||||||||
|
This memo concerns dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre- congestion notification (PCN). 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) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used. | ||||||||||||||||
| draft-ietf-tsvwg-intserv-multiple-tspec-01.txt | |||||||||||||||||
| Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1 | |||||||||||||||||
|
This document defines extensions to Integrated Services (IntServ) allowing multiple traffic specifications and multiple flow specifications to be conveyed in the same Resource Reservation Protocol (RSVPv1) reservation message exchange. This ability helps optimize an agreeable bandwidth through a network between endpoints in a single round trip. | ||||||||||||||||
| draft-ietf-tsvwg-natsupp-02.txt | |||||||||||||||||
| Stream Control Transmission Protocol (SCTP) Network Address Translation Support | |||||||||||||||||
|
Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation (NAPT). To date, specialized code for SCTP has not yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes the protocol extensions required for the SCTP endpoints to help NAT's provide similar features of NAPT in the single-point and multi-point traversal scenario. | ||||||||||||||||
| draft-ietf-tsvwg-rsvp-pcn-01.txt | |||||||||||||||||
| Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains | |||||||||||||||||
|
This document specifies the extensions to the Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. | ||||||||||||||||
| draft-ietf-tsvwg-sctp-udp-encaps-03.txt | |||||||||||||||||
| UDP Encapsulation of SCTP Packets | |||||||||||||||||
|
This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. | ||||||||||||||||
| draft-ietf-tsvwg-source-quench-06.txt | |||||||||||||||||
| Deprecation of ICMP Source Quench messages | |||||||||||||||||
|
This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. | ||||||||||||||||
| draft-ietf-urnbis-rfc2141bis-urn-02.txt | |||||||||||||||||
| Uniform Resource Name (URN) Syntax | |||||||||||||||||
|
Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document serves as the foundation of the 'urn' URI Scheme according to RFC 3986 and sets forward the canonical syntax for URNs, which subdivides URNs into "namespaces". A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. This document supersedes RFC 2141. The requirements and procedures for URN Namespace registration documents are set forth in BCP 66, for which RFC 3406bis is the companion revised specification document replacing RFC 3406. | ||||||||||||||||
| draft-ietf-urnbis-rfc3044bis-issn-urn-00.txt | |||||||||||||||||
| Using International Standard Serial Numbers as Uniform Resource Names | |||||||||||||||||
|
The International Standard Serial Number, ISSN, has been the authoritative identifier for continuing resources (which include serials) for more than three decades. Since 2001, the URN (Uniform Resource Name) namespace "ISSN" has been reserved for ISSNs. The namespace registration was performed in RFC 3044. This document redefines how the revised ISSN standard can be supported within the URN framework, taking into account in particular the latest revision of the ISSN standard in the ISO framework (ISO 3297:2007). Moreover, additional syntax related information required by the RFC 2141[bis] has been included. An updated namespace registration is provided. This document replaces RFC 3044. | ||||||||||||||||
| draft-ietf-urnbis-rfc3187bis-isbn-urn-02.txt | |||||||||||||||||
| Using International Standard Book Numbers as Uniform Resource Names | |||||||||||||||||
|
The International Standard Book Number, ISBN, is a widely used identifier for monographic publications. Since 2001, the URN (Uniform Resource Name) namespace "ISBN" has been reserved for ISBNs. The namespace registration was performed in RFC 3187 and applied only to the ISBN as specified in the ISO Standard 2108-1992, now known as "ISBN-10". To allow for further growth in use, the successor ISO Standard, ISO 2108:2005, has defined an expanded format for the ISBN, known as "ISBN-13". This document defines how both of these ISBN standard versions can be supported within the URN framework. Moreover, additional syntax related information required by RFC 2141[bis] has been included. An updated namespace registration is provided. It describes how both the old and the new ISBN format can share the same namespace. This document replaces RFC 3187; it also obsoletes and moves to Historic status the predecessor thereof, RFC 2288. | ||||||||||||||||
| draft-ietf-urnbis-rfc3188bis-nbn-urn-03.txt | |||||||||||||||||
| Using National Bibliography Numbers as Uniform Resource Names | |||||||||||||||||
|
National Bibliography Numbers, NBNs, are widely used by the national libraries and other organizations in order to identify various resources such as digitized monographs. Generally, NBNs may be applied to all kinds of resources that do not have an established (standard) identifier system of their own. A URN (Uniform Resource Names) namespace for NBNs was established in 2001 in RFC 3188. Since then, several European national libraries have implemented URN:NBN-based systems. This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) is included. | ||||||||||||||||
| draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02.txt | |||||||||||||||||
| Uniform Resource Name (URN) Namespace Definition Mechanisms | |||||||||||||||||
|
Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. To structure and organize their usage, the URN syntax (RFC 2141bis) specifies a hierarchy that divides the set of possible URNs into "URN Namespaces" that can be individually defined and managed. URN Namespaces in particular serve to map existing identifier systems into the URN system and thereby make available generic, network-based resolution services for the identified documents, artifacts, and other objects (and metadata related to them). To achive these goals, URN Namespaces need to be specified in a comparable manner, and their Namespace Identifiers (NIDs) need to be registered with IANA, so that naming conflicts are avoided and implementers of services can follow a structured approach in support of various namespaces, guided by the registry to the related documents and the particularities of specific namespaces, as described in these Namespace registration documents. This RFC serves as a guideline for authors of URN Namespace definition and registration documents and the process to be followed to register a URN Namespace with IANA. It describes the essential content of such documents and how they shall be structured to allow readers familar with the scheme to quickly assess the properties of a specific URN Namespace. This document is a companion document to the revised URN Syntax specification, RFC 2141bis; it supersedes and replaces RFC 3406. | ||||||||||||||||
| draft-ietf-v6ops-464xlat-03.txt | |||||||||||||||||
| 464XLAT: Combination of Stateful and Stateless Translation | |||||||||||||||||
|
This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to mobile and wireline IPv6-only edge networks without encapsulation. | ||||||||||||||||
| draft-ietf-v6ops-6204bis-09.txt | |||||||||||||||||
| Basic Requirements for IPv6 Customer Edge Routers | |||||||||||||||||
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite are covered in the document. The document obsoletes RFC 6204, if approved. | ||||||||||||||||
| draft-ietf-v6ops-icp-guidance-00.txt | |||||||||||||||||
| IPv6 Guidance for Internet Content and Application Service Providers | |||||||||||||||||
|
This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to any enterprise network preparing for IPv6 users. | ||||||||||||||||
| draft-ietf-v6ops-ipv6-discard-prefix-04.txt | |||||||||||||||||
| A Discard Prefix for IPv6 | |||||||||||||||||
|
Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates RFC5156 by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. | ||||||||||||||||
| draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt | |||||||||||||||||
| IPv6 Multihoming without Network Address Translation | |||||||||||||||||
|
Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of NPTv6. However, NAT should be avoided, if at all possible, to permit transparent end-to- end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. We conclude that DHCPv6 based solutions are suitable to solve the multihoming issues, described in this document, while NPTv6 may be required as an intermediate solution. | ||||||||||||||||
| draft-ietf-v6ops-ivi-icmp-address-01.txt | |||||||||||||||||
| Stateless Source Address Mapping for ICMPv6 Packets | |||||||||||||||||
|
A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source that should be passed across the translator as an ICMP packet directed to the the IPv4-translatable destination. This document discusses the considerations and presents a stateless address mapping algorithm for source address translation in ICMPv6 headers for such cases. | ||||||||||||||||
| draft-ietf-v6ops-ra-guard-implementation-04.txt | |||||||||||||||||
| Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) | |||||||||||||||||
|
The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. | ||||||||||||||||
| draft-ietf-v6ops-wireline-incremental-ipv6-03.txt | |||||||||||||||||
| Wireline Incremental IPv6 | |||||||||||||||||
|
Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 dominant environment with long transition period varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. | ||||||||||||||||
| draft-ietf-vcarddav-oma-cab-extensions-02.txt | |||||||||||||||||
| vCard Format extension : represent vCard extensions defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) group | |||||||||||||||||
|
This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance Converged Address Book group, in order to synchronize, using OMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification. | ||||||||||||||||
| draft-ietf-websec-key-pinning-01.txt | |||||||||||||||||
| 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 or more of the pinned fingerprints for that host. By effectively reducing the scope 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 and other authentication errors and attacks. | ||||||||||||||||
| draft-ietf-websec-strict-transport-sec-08.txt | |||||||||||||||||
| HTTP Strict Transport Security (HSTS) | |||||||||||||||||
|
This specification defines a mechanism enabling Web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by Web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. | ||||||||||||||||
| draft-ietf-xmpp-6122bis-02.txt | |||||||||||||||||
| 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 US-ASCII range. This document obsoletes RFC 6122. | ||||||||||||||||
| draft-ietf-xrblock-rtcp-xr-burst-gap-discard-03.txt | |||||||||||||||||
| RTCP XR Report Block for Burst/Gap Discard metric Reporting | |||||||||||||||||
|
This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Discard metrics for use in a range of RTP applications. | ||||||||||||||||
| draft-ietf-xrblock-rtcp-xr-burst-gap-loss-01.txt | |||||||||||||||||
| RTCP XR Report Block for Burst/Gap Loss metric Reporting | |||||||||||||||||
|
This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Loss metrics for use in a range of RTP applications. | ||||||||||||||||
| draft-ietf-xrblock-rtcp-xr-delay-05.txt | |||||||||||||||||
| RTCP XR Report Block for Delay metric Reporting | |||||||||||||||||
|
This document defines an RTCP XR Report Block that allows the reporting of Delay metrics for use in a range of RTP applications. | ||||||||||||||||
| draft-ietf-xrblock-rtcp-xr-discard-02.txt | |||||||||||||||||
| RTCP XR Report Block for Discard metric Reporting | |||||||||||||||||
|
This document defines an RTCP XR Report Block that allows the reporting of a simple discard count metric for use in a range of RTP applications. | ||||||||||||||||
| draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03.txt | |||||||||||||||||
| Real-time Transport Control Protocol (RTCP) Extension Report (XR) for Run Length Encoding of Discarded Packets | |||||||||||||||||
|
The Real-time Transport Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) in to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the jitter buffer after successful reception. | ||||||||||||||||
| draft-ietf-xrblock-rtcp-xr-jb-00.txt | |||||||||||||||||
| RTCP XR Report Block for Jitter Buffer Metric Reporting | |||||||||||||||||
|
This document defines an RTCP XR Report Block that allows the reporting of Jitter Buffer metrics for a range of RTP applications. | ||||||||||||||||
| draft-ietf-xrblock-rtcp-xr-meas-identity-06.txt | |||||||||||||||||
| Measurement Identity and information Reporting using SDES item and XR Block | |||||||||||||||||
|
This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) Block carrying parameters that identify and describe a measurement period, to which one or more other RTCP XR Report Blocks may refer. | ||||||||||||||||
| draft-ietf-xrblock-rtcp-xr-pdv-02.txt | |||||||||||||||||
| RTCP XR Report Block for Packet Delay Variation Metric Reporting | |||||||||||||||||
|
This document defines an RTCP XR Report Block that allows the reporting of Packet Delay Variation metrics for a range of RTP applications. | ||||||||||||||||
| draft-ietf-xrblock-rtcp-xr-qoe-01.txt | |||||||||||||||||
| RTCP XR Blocks for QoE Metric Reporting | |||||||||||||||||
|
This document defines an RTCP XR Report 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. | ||||||||||||||||
| draft-iiban-01.txt | |||||||||||||||||
| 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]. | ||||||||||||||||
| draft-iijima-netconf-websocket-ps-02.txt | |||||||||||||||||
| NETCONF over WebSocket | |||||||||||||||||
|
This memo proposes a way of transporting NETCONF over WebSocket protocol. Web-based applications are increasing with the advancement of Web technologies and emergence of cloud computing. Management systems that support browser-based interface are getting common. It's natural to expect network devices to have browser-based managemaent interface. Currently, however, few network management protocols support the transportation over HTTP. Although NETCONF[RFC6241] was defined to be sent over SOAP/HTTPS[RFC4743], it can not realize notification mechanism[RFC5277] over SOAP/HTTPS since HTTP lacks bi-directional capabilty. But now, WebSocket protocol, the update of HTTP with bi-directional capability, is available[RFC6455]. This memo describes the way NETCONF is sent over WebSocket protocol. | ||||||||||||||||
| draft-inacio-mile-forensics-00.txt | |||||||||||||||||
| Digital Forensics Extension for IODEF | |||||||||||||||||
|
This extension to IODEF (RFC 5070) is designed to aid in the sharing and dissemination of digital forensics information. The goal is to allow a tool independent format to share information between organizations focused on digital forensics: drive images, file carving, metadata, and related hashes. As with IODEF and its extensions, it is defined using XML. | ||||||||||||||||
| draft-ionta-new-multiparty-metrics-framework-01.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ioseb-dzmanashvili-link-relation-07.txt | |||||||||||||||||
| The Create-Form and Edit-Form Link Relations | |||||||||||||||||
|
RFC 5988 [RFC5988] defined the way of indicating resources on the Web. This specification defines link relation types which may be used to express the relationships between a resource and an input form for constructing data submissions. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Apps-Discuss mailing list (see | ||||||||||||||||
| draft-irtf-cfrg-cipher-catalog-00.txt | |||||||||||||||||
| Ciphers in Use in the Internet | |||||||||||||||||
|
This note catalogs the ciphers in use on the Internet, to guide users and standards processes. It presents the security goals, security analysis and results, specification, intellectual property considerations, and publication dates of each cipher. Background information and security guidance is provided as well. | ||||||||||||||||
| draft-irtf-dtnrg-bpq-00.txt | |||||||||||||||||
| Bundle Protocol Query Extension Block | |||||||||||||||||
|
The Bundle Protocol (BP) provides store-and-forward networking for Delay- and Disruption-Tolerant Networks. This document defines the BP query extension block (BPQ) which allows applications to query the stores of nodes on the path along which a bundle containing a bundle query extension block is routed. | ||||||||||||||||
| draft-irtf-dtnrg-prophet-10.txt | |||||||||||||||||
| Probabilistic Routing Protocol for Intermittently Connected Networks | |||||||||||||||||
|
This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the best case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as Delay- and Disruption-Tolerant). The document presents an architectural overview followed by the protocol specification. | ||||||||||||||||
| draft-irtf-hiprg-proxies-05.txt | |||||||||||||||||
| Overview of HIP Proxy Scenarios and Solutions | |||||||||||||||||
|
A Host Identity Protocol (HIP) proxy is a host that holds the keying material, and participates in HIP-based communications, on behalf of one or more hosts. HIP proxies play an important role in the transition from the current Internet architecture to the HIP architecture. A core objective of a HIP proxy is to facilitate the communication between legacy (or Non- HIP) hosts and HIP hosts while not modifying the host protocol stacks. In this document, the legacy hosts served by proxies are referred to as Legacy Hosts (LHs). Currently, various design solutions of HIP proxies have been proposed. These solutions may be applicable in different working circumstances. In this document, these solutions are investigated in detail to compare their effectiveness in different scenarios. | ||||||||||||||||
| draft-irtf-hiprg-revocation-05.txt | |||||||||||||||||
| Host Identifier Revocation in HIP | |||||||||||||||||
|
This document mainly analyzes the key revocation issue with host identifiers (HIs) in the Host Identity Protocol (HIP). Generally, key revocation is an important functionality of key management systems; it is concerned with the issues of removing cryptographic keys from operational use when they are not secure or not secure enough any more. This functionality is particularly important for the security systems expected to execute for long periods. This document also attempts to investigate several issues that a designer of HI revocation mechanisms need to carefully consider. | ||||||||||||||||
| draft-irtf-hiprg-rfid-05.txt | |||||||||||||||||
| HIP support for RFIDs | |||||||||||||||||
|
This document describes an architecture based on the Host Identity Protocol (HIP), for active RFIDs, i.e. Radio Frequency Identifiers including tamper resistant computing resources, as specified for example in the ISO 14443 or 15693 standards. HIP-RFIDs never expose their identity in clear text, but hide this value (typically an EPC- Code) by a particular equation that can be only solved by a dedicated entity, referred as the portal. HIP exchanges occur between HIP-RFIDs and portals; they are transported by IP packets, through the Internet cloud. | ||||||||||||||||
| draft-irtf-rrg-ilnp-adv-03.txt | |||||||||||||||||
| Optional Advanced Deployment Scenarios for ILNP | |||||||||||||||||
|
This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. | ||||||||||||||||
| draft-irtf-rrg-ilnp-arch-03.txt | |||||||||||||||||
| ILNP Architectural Description | |||||||||||||||||
|
This document provides an Architectural description and the Concept of Operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing RG. | ||||||||||||||||
| draft-irtf-rrg-ilnp-arp-03.txt | |||||||||||||||||
| ARP Extension for ILNPv4 | |||||||||||||||||
|
This document defines an Address Resolution Protocol (ARP) extension to support ILNP for IPv4 (ILNPv4). ILNP is is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. | ||||||||||||||||
| draft-irtf-rrg-ilnp-dns-03.txt | |||||||||||||||||
| DNS Resource Records for ILNP | |||||||||||||||||
|
This note describes additional optional Resource Records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing RG. | ||||||||||||||||
| draft-irtf-rrg-ilnp-eng-03.txt | |||||||||||||||||
| ILNP Engineering Considerations | |||||||||||||||||
|
This document describes common (i.e. version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. | ||||||||||||||||
| draft-irtf-rrg-ilnp-icmpv4-03.txt | |||||||||||||||||
| ICMP Locator Update message for ILNPv4 | |||||||||||||||||
|
This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing RG. | ||||||||||||||||
| draft-irtf-rrg-ilnp-icmpv6-03.txt | |||||||||||||||||
| ICMP Locator Update message for ILNPv6 | |||||||||||||||||
|
This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing RG. | ||||||||||||||||
| draft-irtf-rrg-ilnp-noncev6-03.txt | |||||||||||||||||
| IPv6 Nonce Destination Option for ILNPv6 | |||||||||||||||||
|
The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing RG. | ||||||||||||||||
| draft-irtf-rrg-ilnp-v4opts-03.txt | |||||||||||||||||
| IPv4 Options for ILNPv4 | |||||||||||||||||
|
This document defines 2 new IPv4 options that are used only with ILNP for IPv4 (ILNPv4). ILNP is is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. | ||||||||||||||||
| draft-irtf-samrg-common-api-04.txt | |||||||||||||||||
| A Common API for Transparent Hybrid Multicast | |||||||||||||||||
|
Group communication services exist in a large variety of flavors, and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable, upper layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay, and grants access to the different multicast flavors. It proposes an abstract naming by multicast URIs and discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, it describes the application of this API for building gateways that interconnect current multicast domains throughout the Internet. | ||||||||||||||||
| draft-iucg-internet-plus-10.txt | |||||||||||||||||
| Internet+ Architectural Framework | |||||||||||||||||
|
This memo acknowledges the change of scale in network and people centricities within the whole digital ecosystem. It shows how the Internet technology can sustain the resulting network and societal effects in scaling itself from the end to end Internet to a fringe to fringe fully optional and compatible Internet+ which strictly conforms to the Internet architecture and RFCs. It introduces the Internet+ architectural framework and the IUTF to document it. It explores a transition that can be seamlessly immediate and will probably start a complete review and extension of the Internet schemas towards the semiotic Internet (Intersem). | ||||||||||||||||
| draft-iucg-iutf-tasks-01.txt | |||||||||||||||||
| Intelligent Use Task Force | |||||||||||||||||
|
The Intelligent Use Task Force (IUTF) has responsibility for organizing Dedicated Interest Groups (DIG) to research, document and validate solutions in the area of Intelligent Use Interfaces (IUI) between the various components of the whole digital ecosystem (WDE), the resulting intelligent global network (IGNet), the diversity of on-line facilitation services that their IUI and IGNet may bring to people and machines. This document describes the guidelines and procedures for the formation, operations, experimentations and publications of IUTF Dedicated Interest Groups and their internal and external relations with other SDOs (Standardization and Documentation Organizations). Its publication as an IETF Draft is part of the IUCG liaison. | ||||||||||||||||
| draft-iulian-advanced-groupware-access-protocol-05.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-ivancic-mobopts-modemlpa-01.txt | |||||||||||||||||
| Modem Link Properties Advertisement Protocol | |||||||||||||||||
|
Nework devices and applications are increasingly connected to a variety of smart modems whose incoming and outgoing link rates can be varied over time to suit the channel characteristics. Such rate changes can result from use of adaptive coding and modulation. The link rate and conditions offered by the modem to connected devices therefore vary. In order for connected devices and applications to get the most out of the modem's link capacity, it is necessary for the applications and connected devices to condition traffic. Thus, they need some knowledge of the modem's link conditions. This document describes one simple method for a modem to advertise link rate and other characteristics, via UDP messages, and discusses alternative approaches to communicating this information. While the mechanism in this document is described in the context of a modem, it can also be broadly applied to other scenarios such as cryptographic devices. | ||||||||||||||||
| draft-ivov-xmpp-cusax-00.txt | |||||||||||||||||
| Combined Use of the Session Initiation Protocol (SIP) and the eXtensible Messaging and Presence Protocol (CUSAX) | |||||||||||||||||
|
This document describes current 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 complimenting subsets of features from each of the protocols. Typically such subsets would include telephony oriented from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for neither SIP nor XMPP. However, implementing it 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 us should be preferred to the mechanisms provided natively by each protocol like 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. | ||||||||||||||||
| draft-iwijnand-mpls-mldp-multi-topology-01.txt | |||||||||||||||||
| mLDP Extensions for Multi Topology Routing | |||||||||||||||||
|
The Multi-Topology Routing (MTR) enables service differentiation through class-based forwarding. IGP protocols (OSPF and IS-IS) have already been extended to setup MTR. In order to deploy mLDP in an MTR setup, mLDP is also required to become topology-aware. This document specifies extensions to mLDP to support Multi-Topology Routing. | ||||||||||||||||
| draft-jabley-dnssec-trust-anchor-04.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-jacquenet-mpls-rd-p2mp-te-requirements-01.txt | |||||||||||||||||
| Receiver Driven Multicast RSVP TE Requirements | |||||||||||||||||
|
This document presents a set of requirements for the establishment and maintenance of Receiver-Driven Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). | ||||||||||||||||
| draft-jaehwoon-dmm-pmipv6-00.txt | |||||||||||||||||
| PMIPv6-based Distributed Mobility Management | |||||||||||||||||
|
This draft proposes a PMIPv6-based distributed mobility management by distributing the Localized Mobility Anchor (LMA) function to Mobile Access Gateway (MAGs). Here, the MAG that an MN firstly connects to the PMIPv6 domain becomes the MN's LMA, and other MAGs can find the address of the LMA of MN by using the address assigned to the MN. | ||||||||||||||||
| draft-jain-mvpn-bfd-fast-upstream-failover-00.txt | |||||||||||||||||
| BGP Extensions for Multicast VPN Fast Upstream Failover | |||||||||||||||||
|
This document defines BGP extensions and procedures that allows use of BFD for Multi Point Networks for fast detection and failover for upstream faults in Multicast VPNs. The upstream failures addressed in this proposal can be failure of any node between the Root PE and Leaf PE or failure between the Multicast Source and Root PE. | ||||||||||||||||
| draft-jain-pwe3-p2mp-pw-lsp-ping-00.txt | |||||||||||||||||
| Definition of P2MP PW TLV for LSP-Ping Mechanisms | |||||||||||||||||
|
LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PW) using LSP Ping. | ||||||||||||||||
| draft-janapath-intarea-traceflow-00.txt | |||||||||||||||||
| Traceflow | |||||||||||||||||
|
This document describes a new OAM protocol - TraceFlow that captures information pertaining to a traffic flow along the path that the flow takes through the network. TraceFlow is ECMP and link-aggregation aware and captures the information about constituent members through which the traffic flow passes. TraceFlow gathers information that is relevant to the flow such as outgoing interface Layer 3 address, Next-hop to which the packet of the flow is forwarded, effect of network policies such as access control lists on the flow. This draft requires the Traceflow protocol to be processed by Layer 3 devices only. Devices such as Layer 2 devices, MPLS LERs/LSRs along the way are passed through without any processing as if in a pass-through mode. IP tunnels such as IP-in-IP, IP-in-GRE mechanisms are expected to pass the Traceflow packets through them using the pass through mode. For achieving its purpose Traceflow advocates the use of a specific UDP destination port to be assigned from IANA. | ||||||||||||||||
| draft-janapath-opsawg-flowoam-req-00.txt | |||||||||||||||||
| Requirements for OAM tools that enable flow Analysis | |||||||||||||||||
|
This document specifies Operations and Management (OAM) requirements that improve on the traditional OAM tools like Ping and Traceroute. These requirements have arisen from the fact that more details than given by Ping and Traceroute are required while troubleshooting or doing performance and network planning. These requirements have been gathered from network operators especially from data centers where the networks have slightly different characteristics compared to regular campus/carrier networks. | ||||||||||||||||
| draft-jc-pwe3-mpls-tp-static-checking-00.txt | |||||||||||||||||
| Static pseudowire configuration checking using Generic Associated Channel (G-ACh) Advertisement Protocol | |||||||||||||||||
|
This draft introduces a way to do static pseudowire configuration checking, so as to easy the trouble shooting of static PW in MPLS-TP. The idea is to use Generic Associated Channel (G-ACh) Advertisement Protocol (GAP) [I-D.ietf-mpls-gach-adv] in underlying PSN Tunnel to transfer PW configuration parameters, to achieve static PW configuration checking. | ||||||||||||||||
| draft-jdurand-bgp-security-00.txt | |||||||||||||||||
| BGP operations and security | |||||||||||||||||
|
This documents describes best current practices to manage securely BGP in a network. It will explain the basic policies ones should configure on BGP peerings to keep an healthy BGP table. This document will only focus on unicast and multicast tables (SAFI 1 and 2) for IPv4 and IPv6. Foreword A placeholder to list general observations about this document. | ||||||||||||||||
| draft-jenkins-alto-cdn-use-cases-02.txt | |||||||||||||||||
| Use Cases for ALTO within CDNs | |||||||||||||||||
|
For some time, Content Distribution Networks (CDNs) have been used in the delivery of some Internet services (e.g. delivery of websites, software updates and video delivery) as they provide numerous benefits including reduced delivery cost for cacheable content, improved quality of experience for end users and increased robustness of delivery. In order to derive the optimal benefit from a CDN it is preferable to deliver content from the servers (caches) that are "closest" to the End User requesting the content, where "closest" may be as simple as "geographical or network distance" combined with CDN server load within a location, but may also consider other more complex combinations of metrics and CDN or Network Service Provider (NSP) policies. There are a number of different ways in which a CDN may obtain the necessary network topology and/or cost information to allow it to serve End Users from the most optimal servers/locations, such as static configuration, passively listening to routing protocols directly, active probing of underlying network(s), or obtaining topology and cost by querying an information service such as the ALTO map & cost services. This document describes the use cases for a CDN to be able to obtain network topology and cost information from an ALTO server(s). | ||||||||||||||||
| draft-jennings-senml-08.txt | |||||||||||||||||
| Media Types for Sensor Markup Language (SENML) | |||||||||||||||||
|
This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Markup Language (SenML). Representations are defined in JavaScript Object Notation (JSON), eXtensible Markup Language (XML) and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. | ||||||||||||||||
| draft-jennings-vipr-overview-03.txt | |||||||||||||||||
| Verification Involving PSTN Reachability: Requirements and Architecture Overview | |||||||||||||||||
|
The Session Initiation Protocol (SIP) has seen widespread deployment within individual domains, typically supporting voice and video communications. Though it was designed from the outset to support inter-domain federation over the public Internet, such federation has not materialized. The primary reasons for this are the complexities of inter-domain phone number routing and concerns over security. This document reviews this problem space, outlines requirements, and then describes a new model and technique for inter-domain federation with SIP involving the Public Switched Telephone Network (PSTN), called Verification Involving PSTN Reachability (VIPR). VIPR addresses the problems that have prevented inter-domain federation over the Internet. It provides fully distributed inter-domain routing for phone numbers, authorized mappings from phone numbers to domains, a new technique for automated SIP anti-spam, and privacy of number ownership, all while preserving the trapezoidal model of SIP. | ||||||||||||||||
| draft-jennings-vipr-vap-02.txt | |||||||||||||||||
| Verification Involving PSTN Reachability: The ViPR Access Protocol (VAP) | |||||||||||||||||
|
Verification Involving PSTN Reachability (ViPR) is a technique for inter-domain SIP federation. ViPR hybridizes the PSTN, P2P networks, and SIP, and in doing so, addresses the phone number routing and VoIP spam problems that have been a barrier to federation. The ViPR architecture uses a server, the ViPR server, which performs P2P and validation services on behalf of call agents, which acts as clients to the server. Such an architecture requires a client/server protocol between call agents and the ViPR server. That protocol, defined here, is called the ViPR Access Protocol (VAP). | ||||||||||||||||
| draft-jesup-rtcweb-data-protocol-00.txt | |||||||||||||||||
| WebRTC Data Channel Protocol | |||||||||||||||||
|
The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to support for direct interactive rich communication using audio, video, and data between two peers' web- browsers. This document specifies an actual (minor) protocol for how the JS-layer dataChannel objects provide the data channels between the peers. This minor protocol has applicability to other bidirectional uses of SCTP. | ||||||||||||||||
| draft-jesup-rtp-congestion-reqs-00.txt | |||||||||||||||||
| Congestion Control Requirements For Real Time Media | |||||||||||||||||
|
Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real time multimedia, which needs by low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages, and the TCP algorithms are not suitable for this traffic. This document attempts to describe a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose. | ||||||||||||||||
| draft-jiang-dhc-addr-registration-04.txt | |||||||||||||||||
| A Generic IPv6 Addresses Registration Solution Using DHCPv6 | |||||||||||||||||
|
In the IPv6 address allocation scenarios, host self-generated addresses are notionally conflicted with the network managed address architecture. These addresses need to be registered in the networking management plate for the purposes of central address administration. This document introduces a generic address registration solution using DHCPv6, and defines one new ND option and one new DHCPv6 option in order to propagate the solicitations of registering self-generated addresses. The registration procedure reuses the existing IA_NA in the DHCPv6 protocol. | ||||||||||||||||
| draft-jiang-l2vpn-etree-bgp-00.txt | |||||||||||||||||
| E-Tree Support in VPLS with BGP Signaling | |||||||||||||||||
|
This document describes the extension to BGP signaling for the E-Tree support in BGP VPLS when the dual-VLAN model is used as in [Vpls- etree]. The BGP VPLS messages and their procedures remain almost the same as in [RFC4761], only a new extended community for E-Tree is proposed. | ||||||||||||||||
| draft-jiang-netext-ls-pmip-00.txt | |||||||||||||||||
| Load sharing support for MAGs in Proxy Mobile IPv6 | |||||||||||||||||
|
Proxy Mobile IPv6 (PMIPv6) is standardized by IETF to supply mobility management for mobile nodes (MN) in a local small area. When the numbers of MNs which attaching to the same MAG is very large, it will cause the problem that the arrival rate of data traffic is far surpass the process capacity of the MAG. So the MAG will suffer from process bottleneck. The IETF is working on optimization for PMIPv6. This document proposes a load sharing solution for MAGs by migrating the Picked Mobile Node (PMN) to some MAGs without overload to sharing the traffic load, which can relieve stress of the overloaded MAG and improve the performance of PMIPv6 network. | ||||||||||||||||
| draft-jiang-softwire-map-radius-00.txt | |||||||||||||||||
| 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. | ||||||||||||||||
| draft-jiang-v6ops-v4v6mc-proxy-01.txt | |||||||||||||||||
| Multicast Proxy in IPv6/IPv4 Transition | |||||||||||||||||
|
During the long co-existing period of IPv6 and IPv4, the interoperation between IPv6 network and IPv4 network is essential. Multicast services across IPv6 and IPv4 networks are also needed. Besides the packet-based multicast translation mechanism, this document describes a multicast proxy solution. The solution is a multicast deployment for transition scenario. It does not propose any new protocol or protocol modification/extension for multicast. The multicast proxy is deployed at the border of IPv6/IPv4 networks. It is mainly based on content cache. Without packet-based translation, it acquires the content data from IPvX network, caches the data, and multicasts the data in IPvY network. It acts as a multicast leaf in the IPvX network where the data source locates while acting as a multicast source in IPvY network where the multicast client locates. | ||||||||||||||||
| draft-jikim-dmm-pmip-00.txt | |||||||||||||||||
| Use of Proxy Mobile IPv6 for Distributed Mobility Management | |||||||||||||||||
|
This document discusses how to use the Proxy Mobile IPv6 (PMIP) protocol for distributed mobility management. Specifically, we describe the two schemes of distributed mobility management: Signal- driven PMIP (S-PMIP) and Signal-driven Distributed PMIP (SD-PMIP). | ||||||||||||||||
| draft-jimenez-p2psip-coap-reload-01.txt | |||||||||||||||||
| A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD) | |||||||||||||||||
|
This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSN) in a peer-to-peer fashion. The CoAP Usage also provides a rendezvous service for CoAP Nodes and caching of sensor information. The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged. | ||||||||||||||||
| draft-jin-cdni-content-deduplication-optimization-00.txt | |||||||||||||||||
| CDNi Content De-duplication Optimization | |||||||||||||||||
|
Some CDNi deployments are likely to lead to content repetition in the same dCDN. This document gives the cases and then discusses the optimization approach to de-duplicate of the repeated content in CDNi network. To implement the optimization, the enhancement to CDNi metadata model and interface is required. | ||||||||||||||||
| draft-jin-content-deduplication-optimization-00.txt | |||||||||||||||||
| CDNi Content De-duplication Optimization | |||||||||||||||||
|
Some CDNi deployments are likely to lead to content repetition in the same dCDN. This document gives the cases and then discusses the optimization approach to de-duplicate of the repeated content in CDNi network. To implement the optimization, the enhancement to CDNi metadata model and interface is required. | ||||||||||||||||
| draft-jin-jounay-mpls-mldp-hsmp-05.txt | |||||||||||||||||
| Multicast LDP extension for hub & spoke multipoint LSP | |||||||||||||||||
|
This draft introduces a hub & spoke multipoint LSP (short for HSMP LSP), which allows traffic both from root to leaf through P2MP LSP and also leaf to root along the co-routed reverse path. That means traffic entering the HSMP LSP from application/customer at the root node travels downstream, exactly as if it was traveling downstream along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root. A packet traveling upstream should be thought of as being unicast to the root, except that it follows the path of the tree rather than ordinary unicast path. | ||||||||||||||||
| draft-jin-mpls-mldp-leaf-discovery-04.txt | |||||||||||||||||
| Leaf discovery mechanism for mLDP based P2MP/MP2MP LSP | |||||||||||||||||
|
This document describes a mechanism for a root node to discover the leaf nodes of an mLDP based P2MP/MP2MP LSP. Such kind of function could be used for multiplexing/aggregating root initiated and leaf initiated application which will use mLDP based P2MP/MP2MP LSP. Examples of root initiated applications are P2MP PW [I-D.ietf-pwe3-p2mp-pw], VPLS multicast [I-D.ietf-l2vpn-vpls-mcast], L3VPN multicast [RFC6513]. And examples of leaf initiated applications are statically configured mLDP based P2MP/MP2MP LSP, mLDP in-band signaling [I-D.ietf-mpls-mldp-in-band-signaling]. | ||||||||||||||||
| draft-jivsov-openpgp-ecc-14.txt | |||||||||||||||||
| ECC in OpenPGP | |||||||||||||||||
|
This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension. | ||||||||||||||||
| draft-jiyf-ccamp-lsp-03.txt | |||||||||||||||||
| Performance Measurement Metrics of Label Switched Path (LSP) Establishment in Multi-Layer and Multi-Domain Networks | |||||||||||||||||
|
As the increment of network scale, optical networks need to be partitioned into multi-layer and multi-domain networks for the purpose of better management. Meanwhile, as the variety of user requests, different LSPs need to be established. In order to meet different requirements of users, the LSP establishment performance is necessary to be measured in multi-layer and multi-domain networks. For this reason, typical performance measurement metrics need to be proposed. In this document, the LSP establishment delay and bit error ratio (BER), which are both as the performance measurement metrics, are illustrated, and the definition and methodologies are proposed. | ||||||||||||||||
| draft-jjb-mpls-rsvp-te-hsmp-lsp-01.txt | |||||||||||||||||
| Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Hub and Spoke Multipoint Label Switched Paths (LSPs) | |||||||||||||||||
|
In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) environment, the RSVP-TE based Point-to-Multipoint (P2MP) LSP allows traffic to transmit from root to leaf node, but there is no co-routed reverse path for traffic from leaf to root node. This draft introduces a Hub and Spoke Multipoint (HSMP) LSP, which allows traffic from both the root to the leaves through a P2MP LSP and also the leaves to the root along a co-routed reverse path. | ||||||||||||||||
| draft-jobert-tictoc-ptp-link-local-00.txt | |||||||||||||||||
| Transporting PTP messages over MPLS networks using a link local addressing | |||||||||||||||||
|
This document introduces a method for transporting PTP messages over an MPLS network supported by an Ethernet physical layer. The MPLS layer itself is not used to carry the PTP messages with this method; instead, a link local Ethernet channel is used. Several advantages related to this method are highlighted in this document. The method targets in particular telecom applications requiring accurate phase/time synchronization, with "link-by-link" PTP architectures, where all the network nodes support a PTP function, such as Boundary Clock or Transparent Clock. | ||||||||||||||||
| draft-jobert-tsvwg-pre-congest-notif-mobile-00.txt | |||||||||||||||||
| Pre-congestion notification in mobile networks | |||||||||||||||||
|
Mobile networks may be divided into two main segments: the radio segment, and the wireline segment. This document highlights that the algorithms leading to pre-congestion notification (e.g. ECN marking) are usually significantly different for these two segments, and not defined or documented in general over the radio segment. It also explains that using ECN bits leads to having a unique signal for notifying a pre-congestion related to two separate segments with very different notification algorithms. Some consequences are questioned, as well as the potential benefits of being able to identify where the congestion comes from. This document finally discusses the possibility to take into account the radio conditions of the terminals when counting the volume of congestion over the radio segment. | ||||||||||||||||
| draft-johnson-ipfix-mib-variable-export-04.txt | |||||||||||||||||
| Exporting MIB Variables using the IPFIX Protocol | |||||||||||||||||
|
This document specifies a way to complement IPFIX Flow Records with Management Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. This method requires an extension to the current IPFIX protocol. New Template Set and Options Template Sets are specified to allow the export of Simple Network Management Protocol (SNMP) MIB Objects along with IPFIX Information Elements. | ||||||||||||||||
| draft-jokela-hip-rfc5202-bis-02.txt | |||||||||||||||||
| 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). | ||||||||||||||||
| draft-jones-appsawg-webfinger-05.txt | |||||||||||||||||
| WebFinger | |||||||||||||||||
|
This specification defines the WebFinger protocol. WebFinger may be used to discover information about people on the Internet, such as a person's personal profile address, identity service, telephone number, or preferred avatar. WebFinger may also be used to learn information about objects on the network, such as the amount of toner in a printer or the physical location of a server. | ||||||||||||||||
| draft-jones-diameter-abfab-01.txt | |||||||||||||||||
| The Diameter 'Application Bridging for Federated Access Beyond Web (ABFAB)' Application | |||||||||||||||||
|
The Application Bridging for Federated Access Beyond Web (ABFAB) architecture provides cross-domain authentication, authorization and accounting functionality by utilizing well-established technologies, such as Diameter, the Extensible Authentication Protocol (EAP), and the Generic Security Services API (GSS-API). This document defines a Diameter application for usage with the ABFAB architecture to convey authentication information, and authorization decisions from the Diameter server (acting as the identity provider) to the Diameter client (acting as a relying party) encoded in a Security Assertion Markup Language (SAML) encoding. | ||||||||||||||||
| draft-jones-diameter-group-signaling-01.txt | |||||||||||||||||
| Diameter Group Signaling | |||||||||||||||||
|
In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. | ||||||||||||||||
| draft-jones-insipid-session-id-00.txt | |||||||||||||||||
| End-to-End Session Identification in IP-Based Multimedia Communication Networks | |||||||||||||||||
|
This document describes an end-to-end Session Identifier for use in IP-based Multimedia Communication systems that enables endpoints, intermediate devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. | ||||||||||||||||
| draft-jones-insipid-session-id-reqts-00.txt | |||||||||||||||||
| 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, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. | ||||||||||||||||
| draft-jones-ipmc-session-id-reqts-01.txt | |||||||||||||||||
| 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, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. | ||||||||||||||||
| draft-jones-json-web-encryption-json-serialization-01.txt | |||||||||||||||||
| JSON Web Encryption JSON Serialization (JWE-JS) | |||||||||||||||||
|
The JSON Web Encryption JSON Serialization (JWE-JS) is a means of representing encrypted content using JSON data structures. This specification describes a means of representing secured content as a JSON data object (as opposed to the JWE specification, which uses a compact serialization with a URL-safe representation). It enables the same content to be encrypted to multiple parties (unlike JWE). Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. The JSON Serialization for related digital signature and HMAC functionality is described in the separate JSON Web Signature JSON Serialization (JWS-JS) specification. | ||||||||||||||||
| draft-jones-json-web-signature-json-serialization-01.txt | |||||||||||||||||
| JSON Web Signature JSON Serialization (JWS-JS) | |||||||||||||||||
|
The JSON Web Signature JSON Serialization (JWS-JS) is a means of representing content secured with digital signatures or Hash-based Message Authentication Codes (HMACs) using JSON data structures. This specification describes a means of representing secured content as a JSON data object (as opposed to the JWS specification, which uses a compact serialization with a URL-safe representation). It enables multiple digital signatures and/or HMACs to be applied to the same content (unlike JWS). Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. The JSON Serialization for related encryption functionality is described in the separate JSON Web Encryption JSON Serialization (JWE-JS) specification. | ||||||||||||||||
| draft-jones-json-web-token-10.txt | |||||||||||||||||
| JSON Web Token (JWT) | |||||||||||||||||
|
JSON Web Token (JWT) is a means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed or MACed using JSON Web Signature (JWS) and/or encrypted using JSON Web Encryption (JWE). The suggested pronunciation of JWT is the same as the English word "jot". | ||||||||||||||||
| draft-jones-oauth-jwt-bearer-04.txt | |||||||||||||||||
| JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 | |||||||||||||||||
|
This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. | ||||||||||||||||
| draft-jones-simple-web-discovery-02.txt | |||||||||||||||||
| Simple Web Discovery (SWD) | |||||||||||||||||
|
Simple Web Discovery (SWD) defines an HTTPS GET based mechanism to discover the location of a given type of service for a given principal starting only with a domain name. | ||||||||||||||||
| draft-josefsson-kerberos5-i18n-01.txt | ||||||||||||||
| Kerberos V5 Internationalization of Error Messages | ||||||||||||||
| ||||||||||||||